Chapter 3. Using Automatic Mounter Map Options
Prev |  | Next

## Chapter 3. Using Automatic Mounter Map Options

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:

- “Including Group Mounts in Maps”

- “Using Hierarchical Formats in Group Mounts”

- “Specifying Alternative Servers”

- “Using Metacharacters”

- “Using Environment Variables”

- “Including Supplementary Maps”

## 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    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`.

## 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 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. The `utomount` command 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 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, man 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, using `automount`, for you to use the `umount` command to unmount the directory, and inform `automount` of the change in the mount table by using the command `/etc/killall -HUP automount`. Then retry the mount. See the`automount``(1M)` , `killall``(1M)` , and `umount``(1M)` man 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.

## Using Metacharacters

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 in the following subsections.

### Ampersand (&) Metacharacter

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/&

Or assume 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

### Asterisk (*) Metacharacter

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/&

### Backslash (\) Disabling Signal

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 such as:

    /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

### Double Quotation Marks (") String Delimiters

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

## 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 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.

## Including Supplementary Maps

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.

Prev | Table of Contents | Next
Chapter 2. Planning ONC3/NFS Service |  | Chapter 4. Setting Up and Testing ONC3/NFS