What the autofs service does when a mount request is triggered depends on how the automounter maps are configured. The mount process is generally the same for all mounts. However, the final result changes with the mount point that is specified and the complexity of the maps. The mount process includes the creation of the trigger nodes.
To help explain the autofs mount process, assume that the following files are installed.
$ cat /etc/auto_master # Master map for automounter # +auto_master /net -hosts -nosuid,nobrowse /home auto_home -nobrowse /share auto_share $ cat /etc/auto_share # share directory map for automounter # ws gumbo:/export/share/ws
When the /share directory is accessed, the autofs service creates a trigger node for /share/ws, which is an entry in /etc/mnttab that resembles the following entry:
-hosts /share/ws autofs nosuid,nobrowse,ignore,nest,dev=###
When the /share/ws directory is accessed, the autofs service completes the process as follows:
Checks the availability of the server's mount service.
Mounts the requested file system under /share. Now the /etc/mnttab file contains the following entries.
-hosts /share/ws autofs nosuid,nobrowse,ignore,nest,dev=### gumbo:/export/share/ws /share/ws nfs nosuid,dev=#### #####
When multiple layers are defined in the automounter files, the mount process becomes more complex. Suppose that you expand the /etc/auto_shared file from the previous example to contain the following:
# share directory map for automounter # ws / gumbo:/export/share/ws /usr gumbo:/export/share/ws/usr
The mount process is basically the same as the previous example when the /share/ws mount point is accessed. In addition, a trigger node to the next level (/usr) is created in the /share/ws file system so that the next level can be mounted if it is accessed. In this example, /export/share/ws/usr must exist on the NFS server for the trigger node to be created.
Caution - Do not use the –soft option when specifying hierarchical layers. For more information, see Autofs Unmounting.
The unmounting that occurs after a certain amount of idle time is from the bottom up (reverse order of mounting). If one of the directories at a higher level in the hierarchy is busy, only file systems below that directory are unmounted. During the unmounting process, any trigger nodes are removed and then the file system is unmounted. If the file system is busy, the unmount fails and the trigger nodes are reinstalled.
Caution - Do not use the –soft option when specifying hierarchical layers. If the –soft option is used, requests to reinstall the trigger nodes can time out. The failure to reinstall the trigger nodes leaves no access to the next level of mounts. The only way to clear this problem is to have the automounter unmount all of the components in the hierarchy. The automounter can complete the unmounting either by waiting for the file systems to be automatically unmounted or by rebooting the system.