Automount maps offer a number of options that 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.
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,intr ivy:/export/local/iris_bin \ /share –rw,intr willow:/usr/local/share \ /src –ro,intr 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,intr ivy:/export/local/iris–bin /usr/local/share –rw,intr willow:/usr/local/share /usr/local/src –ro,intr 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(1) 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 automounter 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 the automounter 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,intr peach:/export/local \ /bin –ro,intr ivy:/export/local/iris–bin \ /share –rw,intr willow:/usr/local/share \ /src –ro,intr 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. The automounter 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 automount 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,intr oak:/usr/man \ rose:/usr/man \ willow:/usr/man frame –ro,intr 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,intr 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 automounter 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 automounter's RPC requests is selected, and automount(1M) 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 automounter chooses one of the available servers. It is also possible to use the umount(1M) command to unmount the directory, and then inform the automounter of the change in the mount table with the command /etc/killall -HUP automount, and retry the mount. See the automount, killall(1M), and umount(1M) manual pages for more details.
The automounter 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 automounter are described below.
The automounter 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,intr willow:/home/willow:mary joe -ro,intr 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,intr willow:/home/willow:& joe -ro,intr 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 –intr willow:/home/willow peach –ro peach:/home/peach pine pine:/home/pine oak –nosuid,intr oak:/home/oak poplar –nosuid,intr poplar:/home/poplar
Using the ampersand results in entries that look like this:
#Directory Mount Options Location willow –intr &:/home/& peach –ro &:/home/& pine &:/home/& oak –nosuid,intr &:/home/& poplar –nosuid,intr &:/home/&
You can also use directory substitutions in a direct map. For example, assume a direct map contains this entry:
Using an ampersand, this entry can be shortened to this:
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,
the automounter interprets the map entry in this way:
The automounter recognizes an asterisk as a wild card substitution for a directory specification given in a command line. Asterisks must always be the last entry in a map, since the automounter does not read beyond an asterisk entry.
Consider the map in this example:
#Directory Mount Options Location oak –nosuid,intr &:/export/& poplar –nosuid,intr &:/export/& * &:/home/&
In this example, a command line entry with the directory argument redwood is equivalent to this map entry:
In the next map, the last two entries are always ignored:
#Directory Mount Options Location * &:/home/& oak –nosuid,intr &:/export/& poplar –nosuid,intr &:/export/&
The automounter 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 automounter'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 automounter'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
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:
For willow, the entry looks like this:
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 automounter with a command like this:
# /usr/etc/automount –D HOST=`hostname` ...
The entry in the direct map looks like this:
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 automounter to consult the mentioned map as if it were included in the current map. If mapname is a relative pathname (no slashes), the automounter assumes it is an NIS map. If the pathname is an absolute pathname the automounter looks for a local map of that name. If the map name starts with a dash (–), the automounter 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,intr &:/home/& oak –rw,intr &:/export/home +auto.home
If the automounter 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,intr &:/home/& oak –rw,intr &:/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 +auto.home # NIS map +–hosts # built–in hosts map * &:/export/& # wild card
Notice that in all cases the wild card should be the last entry, since the automounter does not continue consulting the map after it reads the asterisk. It assumes the wild card has found a match.