DOC HOME SITE MAP MAN PAGES GNU INFO SEARCH PRINT BOOK
 
Configuring the NFS automounter

How automount works

automount operates during two stages:

automount starts when the command automount(NADM) is executed on a host that will operate as an NFS client. Execution typically takes place at boot time from the command /etc/nfs, but automount can also be executed from the command line. Mandatory for automount operation are one or more files, called ``maps''. These maps contain entries that define what remote filesystems are to be mounted on this client, the mount point for each filesystem, the server that will be the source of each filesystem, and what NFS mount options will characterize each mount. When automount starts, it forks a daemon to serve the mount points specified in the maps. It does this by establishing the daemon as the NFS server for the specified mount points; in effect, it mounts the daemon at these mount points.

When one of these mount points is accessed or crossed, the daemon fields the NFS protocol request as would the real NFS server daemon, nfsd(NADM). The daemon reads the file /etc/mnttab to check whether the remote filesystem is already mounted. If not, the daemon calls a mount routine to mount the filesystem, as specified in the maps. The daemon also records the mount in the file /etc/mnttab. When a predetermined interval has elapsed since the filesystem was accessed, the daemon automatically unmounts the filesystem and removes the record of the mount from the file /etc/mnttab.

Actual and virtual mount points

automount actually mounts all filesystems under the directory /tmp_mnt. It then uses the UNIX operating system's symbolic link support to associate the user-visible mount point with the one in /tmp_mnt. This symbolic link is conceptually similar to a standard UNIX system link(ADM), but it can be established between pathnames residing on different filesystems. The result is that the filesystems, actually mounted under /tmp_mnt, appear to the user to be mounted in a more logical location. See the figures in ``Direct and indirect mounting'' for examples.

Unexpected filesystem behavior

automount's use of symbolic links may produce unexpected effects. For example, automount's method of mounting a filesystem onto the pseudo-staging area /tmp_mnt/... causes undesired results when changing directories using ``..'' in a pathname. If the user issues the command cd .. from the mount point root, he or she ends up in /tmp_mnt, not in the desired parent directory. Similarly, pwd also shows the staging area.

These unexpected effects do not appear if using the Korn shell because this type of shell keeps its own copy of the absolute pathname.

Use of redundant servers

automount allows an NFS client to specify more than one NFS server as the source of a filesystem that the client wishes to mount. For example, if two different servers export an identical read-only directory, an NFS client running automount can include both servers in the maps that the automount daemon reads. When such a duplication of possible servers exists, the automount daemon locates the first available server (using an RPC query) and mounts the filesystem from that system.

One of the obvious benefits of having more than one server from which to mount is that it provides a backup should one of the servers go down or become unreachable. Specifying multiple servers is best used for mounting read-only filesystems. See ``Specifying redundant servers'' for more information and an example.

The mount table

automount uses the same kernel table (/etc/mnttab) as the conventional NFS mounting approach in which to store a record of all active mounts. When automount creates a mount, it adds a record of the mount to /etc/mnttab. When it unmounts a filesystem, it removes the record of that mount from /etc/mnttab. automount keeps an image in memory of /etc/mnttab and refreshes this image every time it performs a mounting or an automatic unmounting.

See also:


Next topic: Direct and indirect mounting
Previous topic: When to use automount

© 2003 Caldera International, Inc. All rights reserved.
SCO OpenServer Release 5.0.7 -- 11 February 2003