How Autofs Works
Autofs is a kernel file system that supports automatic mounting and unmounting. The components that work together to accomplish automatic mounting are:
Autofs is a client-side service that automatically mounts the appropriate file system. The automount service, svc:/system/filesystem/autofs, which is called at system startup time, reads the master map file auto_master to create the initial set of autofs mounts. These autofs mounts are not automatically mounted at startup time but rather are points under which file systems are mounted in the future. These points are also known as trigger nodes. For more information about starting the navigation process, see How Autofs Starts the Navigation Process.
The following figure shows how the autofs service starts the automountd daemon.
Figure 3 svc:/system/filesystem/autofs Service Starts automount
After the autofs mounts are set up, these mounts can trigger file systems to be mounted under them. For example, when autofs receives a request to access a file system that is not currently mounted, autofs calls automountd, which actually mounts the requested file system.
When a request is made to access a file system at an autofs mount point, the following occurs:
-
Autofs intercepts the request.
-
Autofs sends a message to the automountd daemon for the requested file system to be mounted.
-
The automountd daemon locates the file system information in a map, creates the trigger nodes, and performs the mount.
-
Autofs allows the intercepted request to proceed.
-
Autofs unmounts the file system after a period of inactivity.
After initially mounting autofs mounts, use the automount command to update autofs mounts as necessary. The command compares the list of mounts in the auto_master map with the list of mounted file systems in the mount table file /etc/mnttab (formerly /etc/mtab). automount then makes the appropriate changes. This process enables system administrators to change mount information within auto_master and have those changes used by the autofs processes without stopping and restarting the autofs daemon. After the file system is mounted, further access does not require any action from automountd until the file system is automatically unmounted.
Unlike mount, automount does not read the /etc/vfstab file (which is specific to each computer) for a list of file systems to mount. The automount command is controlled within a domain and on computers through the namespace or local files.
Note - Mounts that are managed through the autofs service should not be manually mounted or unmounted. Even if the operation is successful, the autofs service does not check that the object has been unmounted, resulting in possible inconsistencies. A reboot clears all the autofs mount points.
How Autofs Navigates Through the Network
Autofs searches a series of maps to navigate through the network. Maps are files that contain information such as the password entries of all users on a network or the names of all host computers on a network. Effectively, the maps contain network-wide equivalents of UNIX administration files. Maps are available locally or through a network name service such as NIS and LDAP.
Autofs Maps
-
Master map
-
Direct maps
-
Indirect maps
Autofs uses three types of maps:
Master Autofs Map
The auto_master map associates a directory with a map. The map is a master list that specifies all the maps that autofs should check. The following example shows the types of information that an auto_master file could contain.
Example 1 Sample /etc/auto_master File# Master map for automounter # +auto_master /net -hosts -nosuid,nobrowse /home auto_home -nobrowse /nfs4 -fedfs -ro,nosuid,nobrowse /- auto_direct -ro
This example shows the generic auto_master file with one addition for the auto_direct map. Each line in the master map /etc/auto_master has the following syntax:
mount-point map-name [mount-options]
- mount-point
-
Full (absolute) path name of a directory. If the directory does not exist, autofs creates the directory if possible. If the directory exists and is not empty, mounting on the directory hides its contents. In this situation, autofs issues a warning.
The notation /- as a mount point indicates that this particular map is a direct map. The notation also means that no particular mount point is associated with the map.
- map-name
-
Name of the map that autofs uses to find directions to locations, or mount information. If the name is preceded by a slash (/), autofs interprets the name as a local file. Otherwise, autofs searches for the mount information by using the search that is specified in the name-service switch configuration file (/etc/nsswitch.conf). Special maps are also used for /net. For more information, see Mount Point /net.
- mount-options
-
An optional, comma-separated list of options that apply to the mounting of the entries that are specified in map-name, unless the entries in map-name list other options. Options for each specific type of file system are listed in the mount man page for that file system. For information about NFS-specific mount options, see the mount_nfs(1M) man page. For NFS-specific mount points, the bg (background) and fg (foreground) options do not apply.
A line that begins with # is a comment. All the text that follows until the end of the line is ignored.
To split long lines into shorter ones, put a backslash (\) at the end of the line. The maximum number of characters of an entry is 1024.
Note - If the same mount point is used in two entries, the first entry is used by the automount command. The second entry is ignored.
Mount Point /home
The mount point /home is the directory under which the entries that are listed in /etc/auto_home (an indirect map) are to be mounted.
Note - Autofs runs on all computers and supports /net and /home (automounted home directories) by default. You can override these defaults entries in the NIS auto.master map or by local editing of the /etc/auto_master file.
Mount Point /net
Autofs mounts under the directory /net all the entries in the special built-in map -hosts that uses only the hosts database. Suppose that the computer system1 is in the hosts database and it exports any of its file systems. The following command changes the current directory to the root directory of the computer gumbo.
$ cd /net/gumbo
Autofs can mount only the exported file systems of host system1, that is, those file systems on a server that are available to network users instead of those file systems on a local disk. Therefore, all the files and directories on system1 might not be available through /net/system1.
With the /net method of access, the server name is in the path and is location dependent. If you want to move an exported file system from one server to another, the path might no longer work. Instead, you should set up an entry in a map specifically for the file system you want rather than using /net.
Note - Using NFS Version 3 and earlier protocols, autofs checks the server's export list only at mount time. After a server's file systems are mounted, autofs does not check with the server again until the server's file systems are automatically unmounted. Therefore, newly exported file systems are not "seen" until the file systems on the client are unmounted and then remounted. For systems using NFS Version 4, mirror mounts reflect any dynamic changes made to the list of exported file systems on the server.
Mount Point /nfs4
The /nfs4 mount point uses a pseudo-map to mount the FedFS domain root. A reference to the /nfs4/example.net file results in an attempt to find the domain root for the DNS domain example.net and mounts it at that location. Mounting a path under /nfs4 requires that the DNS server returns a record, as described in Set Up a DNS Record for a FedFS Server.
Direct Autofs Maps
A direct map is an automount point. With a direct map, a direct association exists between a mount point on the client and a directory on the server. Direct maps have a full path name and indicate the relationship explicitly. The following example shows a typical /etc/auto_direct map:
/usr/local -ro \
/bin system1:/export/local/sun4 \
/share system1:/export/local/share \
/src system1:/export/local/src
/usr/man -ro system2:/usr/man \
system3:/usr/man \
system4:/usr/man
/usr/games -ro system5:/usr/games
/usr/spool/news -ro system6:/usr/spool/news \
system4:/var/spool/news
Lines in direct maps have the following syntax:
key [mount-options] location
- key
-
Path name of the mount point in a direct map.
- mount-options
-
Options that you want to apply to this particular mount. These options are required only if the options differ from the map default. Options for each specific type of file system are listed in the mount man page for that file system. For information about NFS specific mount options, see the mount_nfs(1M) man page.
- location
-
Location of the file system. One or more file systems are specified as server:pathname for NFS file systems.
Note - The path name should not include an automounted mount point. The path name should be the actual absolute path to the file system. For instance, the location of a home directory should be listed as server:/export/home/username, not as server:/home/username.
As in the master map, a line that begins with # is a comment. All the text that follows until the end of the line is ignored. Put a backslash at the end of the line to split long lines into shorter ones.
Of all the maps, the entries in a direct map most closely resemble the corresponding entries in /etc/vfstab. An entry might appear in /etc/vfstab as follows:
dancer:/usr/local - /usr/local/tmp nfs - yes ro
The equivalent entry appears in a direct map as follows:
/usr/local/tmp -ro dancer:/usr/local
Note - No concatenation of options occurs between the automounter maps. Any options that are added to an automounter map override all options that are listed in maps that are searched earlier. For instance, options that are included in the auto_master map would be overridden by corresponding entries in any other map.
For information about the features of direct autofs map, see How Autofs Selects the Nearest Read-Only Files for Clients.
Mount Point /-
In Example 1, Sample /etc/auto_master File, the mount point /- tells autofs not to associate the entries in auto_direct with any specific mount point. Indirect maps use mount points that are defined in the auto_master file. Direct maps use mount points that are specified in the named map. Note that, in a direct map the key, or mount point, is a full path name.
An NIS auto_master file can have only one direct map entry because the mount point must be a unique value in the namespace. An auto_master file that is a local file can have any number of direct map entries if entries are not duplicated.
Indirect Autofs Maps
An indirect map uses a substitution value of a key to establish the association between a mount point on the client and a directory on the server. Indirect maps are useful for accessing specific file systems, such as home directories. The auto_home map is an example of an indirect map.
Lines in indirect maps have the following general syntax:
key [mount-options] location
- key
-
Name without slashes in an indirect map.
- mount-options
-
Options that you want to apply to this particular mount. These options are required only if the options differ from the map default. Options for each specific type of file system are listed in the mount man page for that file system. For example, see the mount_nfs(1M) man page for NFS-specific mount options.
- location
-
Location of the file system. One or more file systems are specified as server:pathname.
Note - The path name should not include an automounted mount point. The path name should be the actual absolute path to the file system. For instance, the location of a directory should be listed as server:/usr/local, not as server:/net/server/usr/local.
As in the master map, a line that begins with # is a comment. All the text that follows until the end of the line is ignored. Put a backslash (\) at the end of the line to split long lines into shorter ones. Example 1, Sample /etc/auto_master File shows an auto_master map that contains the following entry:
/home auto_home -nobrowse
auto_home is the name of the indirect map that contains the entries to be mounted under /home. A typical auto_home map might contain the following:
user1 server1:/export/home/user1 user2 server2:/export/home/user2 user3 server3:/export/home/user3 user4 server4:/export/home/user4 user5 server5:/export/home/user5 user6 server6:/export/home/user6 user7 -rw,nosuid server7:/export/home/user7
As an example, assume that the previous map is on host master-server. Suppose that the user user7 has an entry in the password database that specifies her home directory as /home/user7. Whenever user7 logs in to computer master-server, autofs mounts the directory /export/home/user7 that resides on the computer server7. Her home directory is mounted read-write, nosuid.
Assume the following conditions occur: User user7's home directory is listed in the password database as /home/user7. Anybody, including user7, has access to this path from any computer that is set up with the master map referring to the auto_home map.
Under these conditions, user user7 can run login or rlogin on any of these computers and have her home directory mounted in place for her.
Furthermore, now user7 can also type the following command:
$ cd ~user1
Autofs mounts user1's home directory for user7 (if all permissions allow).
Note - No concatenation of options occurs between the automounter maps. Any options that are added to an automounter map override all options that are listed in maps that are searched earlier. For instance, options that are included in the auto_master map are overridden by corresponding entries in any other map.
On a network without a name service, you have to change all the relevant files (such as /etc/passwd) on all systems on the network to allow Linda access to her files. With NIS, make the changes on the NIS master server and propagate the relevant databases to the slave servers.
How Autofs Starts the Navigation Process
The automount command reads the master map at system startup. Each entry in the master map is a direct map name or an indirect map name, its path, and its mount options. The specific order of the entries is not important.
Figure 4 Navigation Through the Master Map
This figure shows that automount compares entries in the master map with entries in the mount table to generate a current list.
Autofs Mount Process
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.
Simple Autofs Mount
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=###
-
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 the /share/ws directory is accessed, the autofs service completes the process as follows:
Hierarchical Mounting
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. |
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. |
How Autofs Selects the Nearest Read-Only Files for Clients
This section uses the following example direct map to help explain how autofs selects the nearest read-only files for clients.
/usr/local -ro \
/bin ivy:/export/local/sun4\
/share ivy:/export/local/share\
/src ivy:/export/local/src
/usr/man -ro oak:/usr/man \
rose:/usr/man \
willow:/usr/man
/usr/games -ro peach:/usr/games
/usr/spool/news -ro pine:/usr/spool/news \
willow:/var/spool/news
The mount points /usr/man and /usr/spool/news list more than one location, with three locations for the first mount point and two locations for the second mount point. Any of the replicated locations can provide the same service to any user. This procedure is sensible only when you mount a file system that is read-only, as you must have some control over the locations of files that you write or modify. You want to avoid modifying files on one server on one occasion and, minutes later, modifying the "same" file on another server. The benefit is that the best available server is used automatically without any effort by the user.
If the file systems are configured as replicas (see What Is a Replicated File System?), the NFS clients have the advantage of using failover. Not only is the best NFS server automatically determined, but if that server becomes unavailable, the client automatically uses the next-best server.
An example of a good file system to configure as a replica is man pages. In a large network, more than one server can export the current set of man pages. Which server you mount the man pages from does not matter as long as the server is running and exporting its file systems. In the direct map example, multiple mount locations are expressed as a list of mount locations in the map entry.
/usr/man -ro oak:/usr/man rose:/usr/man willow:/usr/man
-
Number of servers that support a particular NFS protocol level
-
Proximity of the server
-
Weighting
In this example, you can mount the man pages from the servers oak, rose, or willow. Which server is best depends on a number of factors, including the following:
During the sorting process, a count is taken of the number of servers that support each version of the NFS protocol. Whichever version of the protocol is supported on the most servers becomes the protocol that is used by default. This selection provides the client with the maximum number of servers to depend on.
After the largest subset of servers with the same version of the protocol is found, that server list is sorted by proximity. To determine proximity, IPv4 addresses are inspected to determine which servers are in each subnet. Servers on a local subnet are given preference over servers on a remote subnet. Preference for the closest server reduces latency and network traffic.
Note - Proximity cannot be determined for replicas that are using IPv6 addresses.
Server Proximity illustrates server proximity.
Figure 5 Server Proximity
If several servers that support the same protocol are on the local subnet, the time to connect to each server is determined and the fastest server is used. The sorting can also be influenced by using weighting. For more information about weighting, see Autofs and Weighting.
-
Servers on the local subnet are given preference over servers on a remote subnet. So, if a NFS Version 3 server is on the local subnet and the closest NFS Version 4 server is on a remote subnet, the NFS Version 3 server is given preference. Likewise, if the local subnet consists of NFS Version 2 servers, they are given preference over remote subnets with NFS Version 3 and NFS Version 4 servers.
-
If the local subnet consists of a varied number of NFS Version 2, NFS Version 3, and NFS Version 4 servers, more sorting is required. The automounter prefers the highest version on the local subnet. In this instance, NFS Version 4 is the highest version. However, if the local subnet has more NFS Version 3 or NFS Version 2 servers than NFS Version 4 servers, the automounter "bids down" from the highest version on the local subnet by one version. For example, if the local subnet has three servers with NFS Version 4, three servers with NFS Version 3, and ten servers with NFS Version 2, a NFS Version 3 server is selected.
-
Similarly, if the local subnet consists of a varied number of NFS Version 2 and NFS Version 3 servers, the automounter first looks at the which version represents the highest version on the local subnet. Next, the automounter counts the number of servers that run each version. If the highest version on the local subnet also represents the most servers, the highest version is selected. If a lower version has more servers, the automounter bids down from the highest version on the local subnet by one version. For example, if more NFS Version 2 servers are on the local subnet than NFS Version 3 servers, a NFS Version 2 server is selected.
For example, if NFS Version 4 servers are more abundant on the local subnet, NFS Version 4 becomes the protocol that is used by default. However, the sorting process is more complex when servers on the local subnet support different protocols. Here are some examples of how the sorting process works:
Note - Weighting is also influenced by parameters stored in the SMF repository. Specifically the values for server_versmin, client_versmin, server_versmax and client_versmax can exclude some versions from the sorting process. For more information about these parameters, see NFS Daemons.
With failover, the sorting is checked at mount time when a server is selected. Multiple locations are useful in an environment where individual servers might not export their file systems temporarily.
Failover is particularly useful in a large network with many subnets. Autofs chooses the appropriate server and is able to confine NFS network traffic to a segment of the local network. If a server has multiple network interfaces, you can list the host name that is associated with each network interface as if the interface were a separate server. Autofs selects the nearest interface to the client.
Note - No weighting and no proximity checks are performed with manual mounts. The mount command prioritizes the servers that are listed from left to right.
For more information, see automount(1M) man page.
Autofs and Weighting
You can influence the selection of servers at the same proximity level by adding a weighting value to the autofs map. For example:
/usr/man -ro oak,rose(1),willow(2):/usr/man
The numbers in parentheses indicate a weighting. Servers without a weighting have a value of zero and, therefore, are most likely to be selected. The higher the weighting value, the lower the chance that the server is selected.
Note - All other server selection factors are more important than weighting. Weighting is only considered when selecting between servers with the same network proximity.
Variables in an Autofs Map Entry
You can create a client-specific variable by prefixing a dollar sign ($) to its name. The variable helps you to accommodate different architecture types that are accessing the same file system location. You can also use curly braces to delimit the name of the variable from appended letters or digits. The following table shows the predefined map variables.
|
You can use variables anywhere in an entry line except as a key. For instance, suppose that you have a file server that exports binaries for SPARC and x86 architectures from /usr/local/bin/sparc and /usr/local/bin/x86 respectively. The clients can mount through a map entry such as the following:
/usr/local/bin -ro server:/usr/local/bin/$CPU
The same entry for all clients now applies to all architectures.
Note - Most applications that are written for any of the sun4 architectures can run on all sun4 platforms. The –ARCH variable is hard-coded to sun4.
Maps That Refer to Other Maps
Special characters used with map names in map entries in a file map affect how the map name is processed.
-
A map entry +mapname that is used in a file map causes automount to read the specified map as if it were included in the current file.
-
If mapname is not preceded by a slash, autofs treats the map name as a string of characters and uses the name-service switch policy to find the map name. If the path name is an absolute path name, automount checks a local map of that name.
-
If the map name starts with a dash (-), automount consults the appropriate built-in map, such as hosts.
The svc:system/name-service/switch service contains the search order for the naming services. The automount property in the config property group specifies the order that the name service databases are searched when looking for automount entries. If no specific config/automount property is specified, then the order defined in the config/default property is used.
Example 2 Displaying the Search Order of Maps by the automount command$ svcprop -p config svc:/system/name-service/switch config/value_authorization astring solaris.smf.value.name-service.switch config/printer astring user\ files config/default astring files\ nis config/automount astring files\ nis
The example shows that the maps in the local files are searched before the NIS maps. The same would be true if the config/automount property was not specified because the config/default entry would be used. Therefore, you can have a few entries in your local /etc/auto_home map for the most commonly accessed home directories. You can then use the switch to fall back to the NIS map for other entries.
bill cs.csc.edu:/export/home/bill bonny cs.csc.edu:/export/home/bonny
After consulting the included map, if no match is found, automount continues scanning the current map. Therefore, you can add more entries after a + entry.
bill cs.csc.edu:/export/home/bill bonny cs.csc.edu:/export/home/bonny +auto_home
The map that is included can be a local file or a built-in map. Only local files can contain + entries.
+/etc/auto_mystuff # local map +auto_home # NIS map +-hosts # built-in hosts map
Executable Autofs Maps
You can create an autofs map that executes some commands to generate the autofs mount points. Executable autofs maps are useful if you need to be able to create the autofs structure from a database or a flat file. The disadvantage to using an executable map is that the map needs to be installed on each host. An executable map cannot be included in NIS and LDAP name services.
The executable map must have an entry in the auto_master file.
/execute auto_execute
The following example shows a sample executable map:
#!/bin/ksh # # executable map for autofs # case $1 in src) echo '-nosuid,hard bee:/export1' ;; esac
For this example to work, the file must be installed as /etc/auto_execute and must have the executable bit set. Set permissions to 744. Under these circumstances, running the following command causes the /export1 file system from bee to be mounted:
$ ls /execute/src
Default Autofs Behavior With Name Services
At boot time, autofs is invoked by the service svc:/system/filesystem/autofs and autofs checks for the master auto_master map.
Autofs uses the name service ordering specified in the config/automount property of the svc:/system/name-service/switch service. If the config/automount property is not defined, then the config/default property is used. If NIS is selected and autofs cannot find a map that autofs can use, but does find a map name that contains one or more underscores, the underscores are changed to dots to allow traditional NIS file names to work. Then autofs checks the map again. For a name service switch setting of automount: files nis ldap, maps would be found as shown in the following figure.
Figure 6 How Autofs Uses the Name Service
The screen activity for this session would resemble the following example.
$ grep /home /etc/auto_master /home auto_home $ ypmatch brent auto_home Can't match key brent in map auto_home. Reason: no such map in server's domain. $ ypmatch brent auto.home diskus:/export/home/diskus1/&
If "files" is selected as the name service, all maps are assumed to be local files in the /etc directory. Autofs interprets a map name that begins with a slash (/) as local regardless of which name service autofs uses.