Chapter 3. Using Automount Map Options

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:

Including Group Mounts in Maps

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.

Using Hierarchical Formats in Group Mounts

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.

Specifying Alternative Servers

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 \
frame   –ro,intr     redwood:/usr/frame2.0 \

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.

Using Metacharacters

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 Ampersand (&)

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:

/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 automounter interprets the map entry in this way:

/progs              /progs1,/progs2,/progs3:/export/src/progs

The Asterisk (*)

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:

redwood                        redwood:/home/redwood

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 Backslash (\)

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

Double quotes (")

Automount recognizes double quotes (") as string delimiters. Blank spaces within double quotes are not interpreted as the start of a new field. This example illustrates double quotes used to hide the blank space in a two-word name:

/smile                         dentist:/"front teeth"/smile 

Using Environment Variables

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 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 automounter with a command like this:

# /usr/etc/automount –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.

Including Supplementary Maps

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

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
*             –rw              &:/home/&

Finally, the included map can be a local file, or even a built-in map:             # NIS map 
+auto.home.sales               # NIS map         # 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.