Configuring the NFS automounter

Setting advanced automount map options

The sections ``Creating master automount maps'' and ``Creating indirect and direct automount maps'' provide examples for creating master, direct, and indirect automount maps in their basic and simplest form.

automount provides advanced configuration options for use in these maps to ease maintenance, improve automount performance, and provide additional automount capabilities:

``Using built-in automount maps'' illustrates how to specify automount built-in maps for added capabilities.
``Optimizing subdirectory mounting'' explains the use of the ``subdirectory'' field in direct and indirect maps for improved automount performance.
``Simplifying map syntax'' explains the use of substitution characters in maps to ease maintenance.
``Mounting directories from other operating systems'' shows how to incorporate unconventional (for UNIX systems) syntax in automount maps.
``Specifying redundant servers'' illustrates how specifying redundant servers improves resource availability.
``Using multiple direct mounts'' explains how using multiple mounts improves resource access.

Using built-in automount maps

The built-in maps (-hosts, -passwd, and -null) do not need to be created. automount recognizes these names and attaches special automount operations to each. For information on these special operations, see the built-in map descriptions.

Built-in maps are typically used on the automount command line or in the master map. These uses are illustrated below. The -hosts and -passwd maps may also be used in direct and indirect maps. See ``Mixing local and distributed automount maps'' for this usage.

Here are examples of each built-in map used on an automount command line:

automount /net -hosts

automount /home/server -passwd

automount /usr/bin -null

Here is an example of a master map showing usage of each type of built-in map:

   /net               -hosts     mount_options
   /home/server       -passwd    mount_options
   /usr/bin           -null      mount_options

In both of the above examples and for each built-in map type, the built-in map must be associated with a mount point expressed as an absolute pathname.

Optimizing subdirectory mounting

Both direct and indirect maps contain a ``location'' field where the filesystem to be mounted is specified. The syntax of this field is:

server:pathname[:subdirectory]

We recommend that a subdirectory entry be provided in the ``location'' field when different map entries refer to the same mounted filesystem from the same server. This allows automount to work more efficiently. The following example shows a common use of subdirectories that optimizes the work of automount.

This indirect map shows a common way in which automount can be configured to distribute home directories from NFS servers to clients. Such a map may be called auto.home.

   moscow              moscow:/home/moscow
   prague              prague:/home/prague
   zurich              zurich:/home/zurich

Given this indirect map, every time a user wants to access a home directory in, for example, /home/moscow, all the directories under it are mounted. Another way to organize an auto.home map is by user name:

   john                moscow:/home/moscow/john
   mary                moscow:/home/moscow/mary
   joe                 moscow:/home/moscow/joe

The above example assumes that home directories on the NFS client are of the form /home/user rather than /home/server/user. If a user now enters:

   ls ~john ~\mary

automount performs the equivalent of:

mkdir /tmp_mnt/home/john mount -f NFS moscow:/home/moscow/john /tmp_mnt/home/john ln -s /tmp_mnt/home/john /home/john

mkdir /tmp_mnt/home/mary mount -f NFS moscow:/home/moscow/mary /tmp_mnt/home/mary ln -s /tmp_mnt/home/mary /home/mary

It is possible to optimize the work done by automount by modifying the entries in the auto.home map to use the optional ``subdirectory'' field of the ``location'' field of the indirect map. The new auto.home map looks like:

   john                moscow:/home/moscow:john
   mary                moscow:/home/moscow:mary
   joe                 moscow:/home/moscow:joe

Here ``john,'' ``mary,'' and ``joe'' are entries in the ``subdirectory'' field. Now when a user refers to john's home directory, automount mounts moscow:/home/moscow and links /tmp_mnt/home/moscow/john and /home/john.

If the user then requests access to mary's home directory, automount sees that moscow:/home/moscow is already mounted, and simply links /tmp_mnt/home/moscow/mary and /home/mary. Therefore, automount now performs only the equivalent of:

   mkdir /tmp_mnt/home/john
   mount -f NFS moscow:/home/moscow /tmp_mnt/home
   ln -s /tmp_mnt/home/john /home/john
   ln -s /tmp_mnt/home/mary /home/mary

Simplifying map syntax

automount recognizes the ``&'' and ``'' characters as having a special meaning within maps. Using these characters as string substitutions within automount maps reduces redundancy in each line of a map and saves a user from having to duplicate information.

Ampersand (&)

Suppose you have an indirect map with a lot of subdirectories specified, for example:

   john                         moscow:/home/moscow:john
   mary                         moscow:/home/moscow:mary
   joe                          moscow:/home/moscow:joe
   able                         prague:/export/home:able
   baker                        sydney:/export/home:baker
                [.  .  .]

Consider using string substitutions. If the string in the ``key'' field is repeated in the ``location'' field, you can use the ampersand character (&) in place of the key value string wherever it appears in the ``location'' field.

Using the ampersand, the above map now looks like:

   john                         moscow:/home/moscow:&
   mary                         moscow:/home/moscow:&
   joe                          moscow:/home/moscow:&
   able                         prague:/export/home:&
   baker                        sydney:/export/home:&
                [.  .  .]

Suppose the name of the server is the same as the key itself, for instance:

   moscow                       moscow:/home/moscow
   sydney                       sydney:/home/sydney
   prague                       prague:/home/prague
   milan                        milan:/home/milan
   zurich                       zurich:/home/zurich
                [.  .  .]

The use of the ampersand results in:

   moscow                       &:/home/&
   sydney                       &:/home/&
   prague                       &:/home/&
   milan                        &:/home/&
   zurich                       &:/home/&
                [.  .  .]

You can also use key substitutions in a direct map:

   /usr/man                     moscow,seattle,zurich:/usr/man

This could be written as:

   /usr/man                     moscow,seattle,zurich:&

Notice that the ampersand substitution uses the whole key string, so if the key in a direct map starts with a ``/'' (as it should), that slash is carried over, and you could not do something like this:

   /progs                  &1,&2,&3:/export/src/progs

This is because automount interprets it as:

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

Asterisk ()

Notice that all the entries in the ampersand indirect map examples have the same format. This permits you to use the usual substitute character, the asterisk (). The asterisk reduces the whole thing to:

          &:/home/&

Here each ampersand is substituted by the value of any given key. This tells automount to mount /home/server from any known server.

Once automount reads the substitute key, it does not continue reading the map, so that the following map is viable:

   milan           &:/export/&
   zurich          &:/export/&
                  &:/home/&

In the next map the last two entries are always ignored:

                  &:/home/&
   milan           &:/export/&
   zurich          &:/export/&

Mounting directories from other operating systems

Under certain circumstances, you may have to mount directories whose names may confuse automount's map parser. This is a concern only with servers without a UNIX operating system. An example might be a directory called rc0:dk1; this could result in an entry like:

   /patriot          -ro              boston:rc0:dk1

The presence of the two colons in the ``location'' field confuses automount's parser. To avoid this confusion, use a backslash to escape the second colon and remove its special meaning of separator:

   /patriot          -ro              boston:rc0\:dk1

You can also use double quotes where they hide the blank space in the name:

   /marbles                          beijing:/"chinese checkers"/marbles

Specifying redundant servers

Redundant servers can be specified in either a direct or indirect map. In both cases, multiple servers are specified in the ``location'' field of a map entry. In the direct mount example in ``An example of direct mounting using automount'', instead of specifying just london as the remote server for /usr/man, it is possible to specify remote servers madrid and oslo, as well. The resulting direct map could look like:

   /usr/man        -ro,soft   london:/usr/man \
                             madrid:/usr/man \
                             oslo:/usr/man

This means that the mounting can be done from any of the specified locations (london, madrid, or oslo). This list can also be expressed as a list of servers (separated by commas and followed by a colon) and the pathname (as long as the pathname is the same for all of the specified servers), for example:

   /usr/man       -ro,soft    london,madrid,oslo:/usr/man

The first server to respond to the RPC ping issued by automount is selected, and an attempt is made to mount from it. The list does not imply an ordering, although servers on the local network will be contacted first.

CAUTION: Care should be taken when using redundant servers for read-write filesystems because the actual server may change from access to access.

This redundancy, which is very useful in an environment where individual servers may or may not be exporting their filesystems, exists at mount time only. There is no status checking of the mounted-from server by automount once the mount occurs. If the server goes down while the mount is in effect, the filesystem becomes unavailable. An option here is to wait the default five minutes until the auto-unmount takes place and try again. Next time around, automount chooses one of the other, available servers. Another option is to use the umount command, inform automount of the change in the mount table (as specified in the section ``Stopping and restarting automount''), and retry the mount.

Using multiple direct mounts

You can mount multiple remote filesystems to a single local directory with a direct mount configuration. This section compares the two ways in which you can configure direct multiple mounts with an analogous indirect mount.

``An example of indirect mounting using automount'', illustrates an indirect mount where two filesystems, each from a different server, are mounted under a single parent directory. In this indirect mount, each of the remote filesystems is mounted only when that remote filesystem is accessed. Further, if you access one directory, causing it to be mounted, and then try to cd to the other using a relative path, the system will not find or mount the other directory. For example:

cd /doc_tools/spellers
cd ../roff
../roff: No such file or directory

To reach /doc_tools/roff would require:

cd /doc_tools/roff

If you access /doc_tools/roff before executing cd ../roff, with the ls command for example, then /doc_tools/roff gets mounted and you can reach it using a relative path.

Here is an example showing one way in which you could mount the same two remote filesystems under a single parent, but using a direct mount configuration:

   /doc_tools/spellers     -ro,soft   madrid:/doc.stuff/spellers
   /doc_tools/roff         -ro,soft   oslo:/doc/bin/roff

Like the indirect mount configuration, each of the remote filesystems here is mounted separately and only when that remote filesystem is accessed. With this configuration, if you access one directory, causing it to be mounted, and then try to cd to the other using a relative path, automount will mount the other filesystem and place the user in the desired directory if the user is running ksh. If the user is not running ksh, the system will not find or mount the other directory, as in the indirect map configuration.

Here is an example showing a second way in which you can mount the same two remote filesystems under a single parent, but using a single direct configuration.

   /doc_tools \
                  /spellers    -ro,soft   madrid:/doc.stuff/spellers \
                  /roff        -ro,soft   oslo:/doc/bin/roff

With this configuration, both filesystems are mounted if either one is accessed. Because both filesystems are always mounted at the same time, a cd using a relative path between the two filesystems will work regardless of the shell being used. Note that the syntax of this configuration differs from the direct map syntax shown in ``About automount maps''. The parent directory appears on the first line with a ``\'' indicating a continued entry. Each subsequent line contains a mount point (that begins with a slash), options, and a location. Redundant locations can be specified as described in ``Specifying redundant servers''.

This ``unified mount'' has these advantages over the previous direct mount example:

Improved system performance through less mount activity and one fewer mount point's being needed.
Relative path movement without qualifications.

The ``unified mount'' has these advantages over the indirect mount configuration:

Improved system performance through less mount activity and one fewer mount point's being needed.
Relative path movement without qualifications.
Ability to cd to the parent directory; since the indirect mount creates a virtual parent directory only, you cannot cd to that directory. See ``Unexpected filesystem behavior'' for more information on how the shell's being used affects behavior.

Remember, however, that an indirect mount configuration always has one advantage over direct mount configurations: indirect mount points under the virtual parent can be reconfigured without restarting automount. Changing direct mount configurations requires restarting automount. See ``Understanding map modifications''.

The above examples show remote filesystems residing on different servers. The above examples would still be valid if all remote filesystems were from the same server or there were more than two remote filesystems being mounted and all were from different servers.

If unified direct mounts share the same options, it is not necessary to duplicate these options for each server. Rather, the options can precede the different mounts:

   /doc_tools             -ro,soft   \
               /spellers            madrid:/doc.stuff/spellers \
               /roff                oslo:/doc/bin/roff

If one of the mount points needs a different specification, modify only its options:

   /doc_tools             -ro,soft   \
               /spellers  -rw       madrid:/doc.stuff/spellers \
               /roff                oslo:/doc/bin/roff

A special case of multiple direct mounts occurs when the root of a filesystem has to be mounted as well. This is called a ``hierarchical'' mount. A true hierarchical mount might be:

   /usr/local \                  
           /                   prague:/usr/local \
           /bin    -ro,soft     tokyo:/usr/local/bin \
           /src    -ro          milan:/usr/local/src

NOTE: A true hierarchical mount can be problematic if the server for the root of the filesystem goes down. Any attempt to unmount the lower branches fails, because the unmounting has to proceed through the mount root, which also cannot be unmounted while its server is down.