The use of automount maps involves map formats, replicated file systems, comments in maps, directory patterns, multiple mounts, included maps, maps for the automount command, and the auto_master (or, when necessary for compatibility, auto.master) map file.
A simple map entry (mapping) example follows:
key [-mount-options] location ...
where
hostname:pathname
where hostname is the server name where the file system will mount and pathname is the directory path to mount.
Multiple location fields can be specified for replicated NFS file systems, in which case automount and the kernel each tries to use that information to increase availability. If the read-only flag is set in the map entry, automount mounts a list of locations that the kernel may use, sorted by several criteria. If a server does not respond, the kernel switches to an alternative server. Sort ordering is used by automount to determine how the next server is chosen. If the read-only flag is not set, automount mounts the best single location, chosen by the same sort ordering, and new servers are chosen only when an unmount has been possible and a remount is done. Servers on the same local subnet are given first preference, and servers on the local net are given second preference. Among servers equally far away, response times determine the order (if no weighting factors are used).
If the list includes server locations using both Versions 2 and 3 of the NFS protocol, automount chooses only a subset of the server locations on the list to ensure all entries are the same protocol level. It gives preference to Version 3 servers and uses Version 2 servers if Version 3 servers are unavailable.
If each location in the list shares the same path name, a single location can be used with a list of host names, separated by commas.
hostname,hostname...:pathname
Requests for a server can be weighted by appending the weighting factor (as an integer within parentheses) to the server name. A weighting factor of zero is the highest priority. Servers without a weighting factor are assumed to have a weighting factor of zero. Progressively higher values decrease a server's chance of being selected. In the following example,
hosts masterlib and mystery have the highest priority; host doyle, the lowest.
man -ro masterlib,mystery,christie(1),doyle(4):/usr/man
Note: In the selection process, server proximity takes higher priority than weighting. In the previous example, if server doyle were on the same network as the user and the other servers were on different network segments, then doyle would be selected and the weighting value would be ignored.When each server has a different export point, you can still apply weighting. For example:
man -ro masterlib:/usr/man mystery,christie(1):/usr/share/man doyle(3):/export/manMapping can be continued across input lines by escaping the newline character with a backslash (\). Comments begin with a pound sign (#) and end at the subsequent newline character.
The ampersand (&) character is expanded to the value of the key field for the entry in which it occurs. In the following example, the ampersand expands to suspense.
suspense
masterlib:/thriller/&
When used in the key field, the asterisk (*) is recognized as a catch-all entry. The asterisk matches any key not previously matched. For instance, if the following entry appears in the indirect map for /mystery:
*
&:/masterlib/mystery/&
the entry would allow automatic mounts in /mystery of any remote file system whose location was specified as
hostname:/masterlib/mystery/hostname
A multiple mount entry takes the following form:
key [-mount-options] [ [/mountpoint] [-mount-options] location ... ] ...
The initial /[mountpoint] is optional for the first mount and mandatory for all subsequent mounts. The optional mountpoint is taken as a pathname relative to the directory named by key. If mountpoint is omitted in the first occurrence, a mountpoint of / (root) is implied. The following is an example entry in the indirect map for /src:
beta -ro\
/ svr1,svr2:/export/src/beta \
/1.0 svr1,svr2:/export/src/beta/1.0 \
/1.0/man svr1,svr2:/export/src/beta/1.0/man
All offsets must exist on the server under beta.automount, which automatically mounts /src/beta, /src/beta/1.0, and /src/beta/1.0/man, as needed, from either svr1 or svr2 (whichever is nearer and responds more quickly).
The initial / (forward slash) within /[mountpoint] is required. The optional mount point is taken as a path name relative to the destination of the symbolic link for key. If the mountpoint option is omitted in the first occurrence, a mount point of / (or the root directory) is assumed.
The automounter assumes NFS mounts as a default file system type. Other file system types can be described using the fstype mount option. Other mount options specific to this file system type can be combined with the fstype option. The location field must contain information specific to the file system type. If the location field begins with a slash (/), a colon (:) must be prepended. To mount a CD file system, use the following example:
cdrom -fstype=cdrfs,ro :/dev/cd0
To perform an autofs mount, use the following example:
src -fstype=autofs auto_src
An indirect map allows you to specify mappings for the subdirectories you wish to mount under the directory indicated on the command line. In an indirect map, each key consists of a simple name that refers to one or more file systems that are to be mounted as needed.
Entries in a direct map are associated directly with autofs mount points. Each key is the full path name of an autofs mount point. The direct map, as a whole, is not associated with any single directory.
There are two special maps available: -hosts and null. The -hosts map is used with the /net directory and assumes that the map key is the host name of an NFS server. The automountd daemon dynamically constructs a map entry from the server's list of exported file systems. For example, a reference to /net/sales/usr would initiate an automatic mount of all exported file systems from sales that are mountable by the client. References to a directory under /net/sales would refer to the corresponding directory relative to the sales root.
The -null map, when indicated on the command line, cancels a previous map for the directory indicated. This is used in the /etc/auto_master map for canceling entries that would otherwise be inherited from the +auto_master include entry. The -null entries must be inserted before the included map entry.
Note: Local maps that have the executable bit set in their file permissions are executed by the automounter and provided with a key to be looked up as an argument.
An executable map returns the content of an automounter map entry into standard output (stdout) or returns no output if the entry cannot be determined.
When initiated without arguments, automount consults the master map for a list of autofs mount points and their maps. It mounts any autofs mounts that are not already mounted and unmounts autofs mounts that have been removed from the master map or direct map. The automount command may be initiated to establish mounts by specifying the map information on the command line. This information can be lost if the automount command is invoked a second time. For the sake of administration and debugging, the automount command writes a reference map file that reflects the map information specified on the command line. The file is generated on each invocation of the command and is called /etc/autofs_cmdline.
Note: The master map can be called auto_master or auto.master. If auto_master isn't found, NIS looks for auto.master.
The contents of another map can be included within another map by entering:
+mapname
The mapname can be a file name or the name of an NIS map. Or, mapname can be one of the special maps described in the following section. If the key being searched for is not located in an included map, the search continues with the next entry.
The following procedure addresses the most common management tasks for NIS automount maps.
NIS must be configured on your network. See NIS Installation and Configuration for further information.
DirectoryPath AutomountMapName
The AutomountMapName field specifies a file containing the automount map for the directory specified by the DirectoryPath field. For example, the contents of the /etc/auto.master file on the NIS server might be as follows:
/home/home /etc/auto.home /usr/lpp /etc/auto.direct
The above auto.master file entries direct the automount daemon to use the /etc/auto.home automount map for the /home/home directory and the /etc/auto.direct automount map for the /usr/lpp directory.
Subdirectory MountOptions ServerName:ServerDirectory
The Subdirectory field specifies a subdirectory of the DirectoryPath field directory of the auto.master file. For example, the contents of the /etc/auto.home file on the NIS client might be as follows:
john -rw,hard,intr host1:/home/john bill -rw,hard,intr host3:/home/bill sally -rw,hard,intr host5:/home/sally fred -rw,hard,intr host9:/home/fred jane -rw,hard,intr host1:/home/jane
The contents of the /etc/auto.direct file on the NIS client might be as follows:
X11 -ro,hard,intr lppserver:/usr/lpp/X11 bsmEn_US -ro,hard,intr lppserver:/usr/lpp/bsmEn_US gnuemacs -ro,hard,intr lppserver:/usr/lpp/gnuemacs info -ro,hard,intr lppserver:/usr/lpp/info
auto.master.time: $(DIR)/auto.master
-@if [ -f $(DIR)/auto.master ] ; then \
$(MAKEDBM) $(DIR)/auto.master $(YPDBDIR)/$(DOM)/auto.master; \
touch auto.master.time ; \
echo "updated auto.master" ; \
if [ ! $(NOPUSH) ] ; then \
$(YPPUSH) auto.master ; \
echo "pushed auto.master" ; \
else \
: ; \
fi \
else \
echo "couldn't find $(DIR)/auto.master" ; \
fi
In general, the same format that is used for the netmasks entry in the Makefile file can be used for the auto.master entry.
make auto.master
If errors are generated, check for improper configuration of NIS, errors in the Makefile file, or errors in the syntax of the /etc/auto.master file.
/usr/sbin/automount
This starts the automount daemon, which reads the auto.master NIS map.
In the preceding examples, when these procedures are completed, a user on the client can issue the cd /home/home/bill command and have the /home/bill directory mounted from the host3 system onto the /home/home/bill directory.
In the first example, the /etc/auto.home and /etc/auto.direct were local files on the client that contained all of the automount map needed. The contents of the automount maps can also be maintained by NIS. The files would still exist on the client, but the contents would be different. For example, the /etc/auto.home file would contain the following:
+auto.home
And the /etc/auto.direct file would contain the following:
+auto.direct
This directs the automount daemon to consult the NIS maps auto.home and auto.direct when it reads the local files. The NIS server would contain two new NIS maps. The maps would be auto.home and auto.direct. They would be added to the /var/yp/Makefile in the same way that the auto.master NIS map was added. This makes them available for use by the NIS clients running the automount daemon.
This facility can also be used to define local portions of the automount maps and then refer to the NIS maps for the rest of the automount map. For example, the /etc/auto.home file could contain the following:
sandy -rw,hard,intr host10:/home/sandy james -rw,hard,intr host2:/home/james bill -rw,hard,intr host20:/home/bill +auto.home
This automount map has three local entries and also contains the NIS map auto.home. This way, local definitions can be maintained while taking advantage of the NIS map for the /home/home directory. The entry bill in the local map would appear in the auto.home NIS map. The local map entry overrides the NIS map entry.