Automatic mounter (automount and autofs) maps offer a number of options to increase mounting efficiency and make map building easier. This chapter explains each option and provides examples of how to include them in maps. Except as noted, the options described in this chapter can be used in either direct or indirect maps. Direct maps are not supported in autofs.
This chapter contains these sections:
Group mounts are a means of organizing entries in a direct map so that a single mount provides several directories that users are likely to need simultaneously. Group mounts work only with direct maps. The map entry for a group mount specifies the parent directory to be mounted. Subentries specify the individual child directories the mount makes available and any mount options that apply to them. The directories in a group mount need not be on the same server.
A sample group mount entry is:
/usr/local \
/bin –ro ivy:/export/local/iris_bin \
/share –rw willow:/usr/local/share \
/src –ro oak:/home/jones/src
|
This example shows that, when /usr/local is mounted, users have access to three directories: /export/local/iris_bin, a read-only directory on server ivy; /usr/local/share, a read-write directory on server willow; and /home/jones/src, a read-only directory on server oak. The backslash (\) at the end of a line indicates that a continuation line follows. Continuation lines are indented with blank spaces or tabs.
Without the group mount feature, the single entry shown in the previous example would require three separate mounts and three individual map entries, as shown in this example:
/usr/local/bin –ro ivy:/export/local/iris–bin /usr/local/share –rw willow:/usr/local/share /usr/local/src –ro oak:/home/jones/src |
Group mounts and separate entries differ in that group mounts guarantee that all directories in the group are mounted whenever any one of them is referenced. This is not the case for separate entries. For example, notice the error message that occurs in this sequence when the user specifies a relative pathname to change directories:
% cd /usr/local/bin % cd ../src UX:csh:ERROR: ../src - No such file or directory |
The error occurs because the directory /usr/local/src is not mounted with /usr/local/bin. A separate cd command is required to mount /usr/local/src.
When the root of a file hierarchy must be mounted before any other mounts can occur, it must be specified in the map. A hierarchical mount is a special case of group mounts in which directories in the group must be mounted in a particular order. For hierarchical mounts, the automatic mounter must have a separate mount point for each mount within the hierarchy.
The sample group mount entry shown in the previous section illustrates nonhierarchical mounts under /usr/local when /usr/local is already mounted, or when it is a subdirectory of another mounted system. The concept of root here is very important. The symbolic link returned by automount to the kernel request is a path to the mount root, the root of the hierarchy mounted under /tmp_mnt.
An example of a hierarchical mount is:
/usr/local \
/ –rw peach:/export/local \
/bin –ro ivy:/export/local/iris–bin \
/share –rw willow:/usr/local/share \
/src –ro oak:/home/jones/src
|
The mount points used here for the hierarchy are /, /bin, /share, and /src. These mount point paths are relative to the mount root, not to the system's file system root. The first entry in this example has / as its mount point. It is mounted at the mount root. The first mount of a hierarchy is not required to be at the mount root. Automount creates directories to build a path to the first mount point if the mount point is not at the mount root.
A true hierarchical mount can be a disadvantage if the server of the root hierarchy becomes unavailable. When this happens, any attempt to unmount the lower branches fail, since unmounting must proceed through the mount root, and the mount root cannot be unmounted while its server is unavailable.
In an automatic mounter map, you can specify alternative servers to be used in the event the specified server is unavailable when mounting is attempted. This example illustrates an indirect map in which alternative servers are used:
man –ro oak:/usr/man \
rose:/usr/man \
willow:/usr/man
frame –ro redwood:/usr/frame2.0 \
balsa:/export/frame
|
The mount point man lists three server locations, and frame lists two. Mounting can be done from any listed server, as long as it is available.
Alternative locations are recommended for mounting read-only hierarchies. However, they are not advised for read-write files, since alternating versions of writable files causes problems with version control.
In the example above, multiple mount locations are expressed as a list of mount locations in the map entry. They can also be expressed as a comma-separated list of servers, followed by a colon and the pathname, if the pathname is the same for all alternate servers:
man –ro oak,rose,willow:/usr/man |
In this example, manual pages are mounted from either oak, rose, or willow, but this list of servers does not imply order. However, the automatic mounter does try to connect to servers on the local network first before soliciting servers on a remote network. The first server to respond to the automatic mounter's RPC requests is selected, and automount or autofs attempts to mount the server.
Although this redundancy is very useful in an environment where individual servers may or may not be exporting their file systems, it is beneficial at mount time only. If a server goes down while a mount is in effect, the directory becomes unavailable. An option here is to wait 5 minutes until the auto-unmount takes place and try again. At the next attempt, the automatic mounter chooses one of the available servers. It is also possible, with automount, for you to use the umount command to unmount the directory, and inform automount of the change in the mount table with the command /etc/killall -HUP automount. Then retry the mount. See the automount(1M), killall(1M), and umount(1M) reference pages for more details. Since the autofs daemon holds no state, you need only use the umount command to unmount the directory, then retry access.
The automatic mounter recognizes some characters, metacharacters, as having a special meaning. Metacharacters are used to do substitutions and to disable the effects of special characters. Metacharacters recognized by the automatic mounter are described below.
The automatic mounter recognizes an ampersand as a string substitution character. It replaces ampersands in the location field with the directory field character string specification wherever the ampersand occurs in the location specification. For example, assume you have a map containing many subdirectory specifications, like this:
#Directory Mount Options Location john -nodev willow:/home/willow/john mary -nosuid willow:/home/willow/mary joe -ro willow:/home/willow/joe able pine:/export/home/able baker peach:/export/home/baker |
Using the ampersand, the map above looks like this:
#Directory Mount Options Location john -nodev willow:/home/willow/& mary -nosuid willow:/home/willow/& joe -ro willow:/home/willow/& able pine:/export/home/& baker peach:/export/home/& |
Let's say the server name and directory name are the same, as in this example:
#Directory Mount Options Location willow willow:/home/willow peach –ro peach:/home/peach pine pine:/home/pine oak –nosuid oak:/home/oak poplar –nosuid poplar:/home/poplar |
Using the ampersand results in entries that look like this:
#Directory Mount Options Location willow &:/home/& peach –ro &:/home/& pine &:/home/& oak –nosuid &:/home/& poplar –nosuid &:/home/& |
You can also use directory substitutions in a direct map. For example, assume a direct map contains this entry:
/usr/man willow,cedar,poplar:/usr/man |
Using an ampersand, this entry can be shortened to this:
/usr/man willow,cedar,poplar:& |
Notice that the ampersand substitution uses the whole directory string. Since directory specifications in a direct map begin with a slash (/), it is important to remember that the slash is carried over when you use the ampersand. For example, if a direct map contains this entry,
/progs &1,&2,&3:/export/src/progs |
the automatic mounter interprets the map entry in this way:
/progs /progs1,/progs2,/progs3:/export/src/progs |
The automatic mounter recognizes an asterisk as a wildcard substitution for a directory specification given in a command line. Asterisks must always be the last entry in a map, since the automatic mounter does not read beyond an asterisk entry.
Consider the map in this example:
#Directory Mount Options Location oak –nosuid &:/export/& poplar –nosuid &:/export/& * &:/home/& |
In this example, a command line entry with the directory argument redwood is equivalent to this map entry:
redwood redwood:/home/redwood |
In the next map, the last two entries are always ignored:
#Directory Mount Options Location * &:/home/& oak –nosuid &:/export/& poplar –nosuid &:/export/& |
The automatic mounter recognizes the backslash as a signal to disable the effects of the special character that follows it. It interprets the special character literally. For example, under certain circumstances, you might need to mount directories whose names could confuse the automatic mounter's map parser. An example might be a directory called rc0:dk1. This name could result in an entry like:
/junk –ro vmsserver:rc0:dk1 |
The presence of the two colons in the location field confuses the automatic mounter's parser. To avoid this confusion, use a backslash to escape the second colon and remove its special meaning of separator:
/junk –ro vmsserver:rc0\:dk1 |
The automatic mounter recognizes double quotation marks (") as string delimiters. Blank spaces within double quotation marks are not interpreted as the start of a new field. This example illustrates double quotation marks used to hide the blank space in a two-word name:
/smile dentist:/"front teeth"/smile |
You can use the value of an environment variable by prefixing a dollar sign to its name. You can also use braces to delimit the name of the variable from appended letters or digits. Environment variables can appear anywhere in an entry line, except as a directory.
The environment variables can be inherited from the environment or can be defined explicitly with the –D command line option. For instance, if you want each client to mount client–specific files in the network in a replicated format, you could create a specific map for each client according to its name, so that the relevant line for the system oak looks like this:
/mystuff acorn,ivy,balsa:/export/hostfiles/oak |
For the system willow, the entry looks like this:
/mystuff acorn,ivy,balsa:/export/hostfiles/willow |
This scheme is viable within small networks, but maintaining system-specific maps across a large network is burdensome. An alternative for large networks is to start the automatic mounter with either of these commands:
/usr/etc/automount –D HOST=`hostname` ... |
or
/usr/etc/autofs –D HOST=`hostname` ... |
The entry in the direct map looks like this:
/mystuff acorn,ivy,balsa:/export/hostfiles/$HOST |
Now each system finds its own files in the mystuff directory, and centralized administration and distribution of maps is easier.
A line of the form +mapname causes the automatic mounter to consult the mentioned map as if it were included in the current map. If mapname is a relative pathname (no slashes), the automatic mounter assumes it is an NIS map. If the pathname is an absolute pathname the automatic mounter looks for a local map of that name. If the map name starts with a dash (–), the automatic mounter consults the appropriate built-in map.
For instance, you can have a few entries in your local auto.home map for the most commonly accessed home directories and follow them with the included NIS map, as shown in this example:
ivy –rw &:/home/& oak –rw &:/export/home +auto.home |
If the automatic mounter finds no match in the included map, it continues scanning the current map. This allows you to use additional entries after the included map, as shown in this example:
ivy –rw &:/home/& oak –rw &:/export/home +auto.home * –rw &:/home/& |
Finally, the included map can be a local file, or even a built-in map:
+auto.home.finance # NIS map +auto.home.sales # NIS map +auto.home.engineering # NIS map +/etc/auto.mystuff # local map +yourstuff /etc/yourstuff # local map +auto.home # NIS map +–hosts # built–in hosts map * &:/export/& # wildcard |
Notice that in all cases the wildcard should be the last entry, since the automatic mounter does not continue consulting the map after it reads the asterisk. It assumes the wildcard has found a match.