Previous Page
Next Page

AutoFS

Objective:

Explain how to configure AutoFS using automount maps.

When a network contains even a moderate number of systems, all trying to mount file systems from each other, managing NFS can quickly become a nightmare. The AutoFS facility, also called the automounter, is designed to handle such situations by providing a method by which remote directories are mounted automatically, only when they are being used. AutoFS, a client-side service, is a file system structure that provides automatic mounting.

When a user or an application accesses an NFS mount point, the mount is established. When the file system is no longer needed or has not been accessed for a certain period, the file system is automatically unmounted. As a result, network overhead is lower, the system boots faster because NFS mounts are done later, and systems can be shut down with fewer ill effects and hung processes.

File systems shared through the NFS service can be mounted via AutoFS. AutoFS is initialized by automount, which is run automatically when a system is started. The automount daemon, automountd, runs continuously, mounting and unmounting remote directories on an as-needed basis.

Mounting does not need to be done at system startup, and the user does not need to know the superuser password to mount a directory (normally file system mounts require superuser privilege). With AutoFS, users do not use the mount and umount commands. The AutoFS service mounts file systems as the user accesses them and unmounts file systems when they are no longer required, without any intervention on the part of the user.

However, some file systems still need to be mounted by using the mount command with root privileges. For example, on a diskless computer you must mount / (root), /usr, and /usr/kvm by using the mount command, and you cannot take advantage of AutoFS.

Two programs support the AutoFS service: automount and automountd. Both are run when a system is started by the svc:/system/filesystem/autofs:default service identifier.

The automount service sets up the AutoFS mount points and associates the information in the /etc/auto_master files with each mount point. The automount command, which is called at system startup time, reads the master map file /etc/auto_master to create the initial set of AutoFS mounts. These mounts are not automatically mounted at startup time. They are trigger points, also called trigger nodes, under which file systems are mounted in the future. The following is the syntax for automount:

automount -t <duration> -v

Table 9.11 describes the syntax options for the automount command.

Table 9.11. automount Command Syntax

Option

Description

-t <duration>

Sets the time, in seconds, that a file system is to remain mounted if it is not being used. The default value is 600 seconds.

-v

Selects verbose mode. Running the automount command in verbose mode allows easier troubleshooting.


If it is not specifically set, the value for duration of an unused mount is set to 10 minutes. In most circumstances, this value is good; however, on systems that have many automounted file systems, you might need to decrease the duration value. In particular, if a server has many users, active checking of the automounted file systems every 10 minutes can be inefficient. Checking AutoFS every 300 seconds (5 minutes) might be better. You can edit the /etc/default/autofs script to change the default values.

If AutoFS receives a request to access a file system that is not currently mounted, AutoFS calls automountd, which mounts the requested file system under the trigger node.

The automountd daemon handles the mount and unmount requests from the AutoFS service. The syntax of this command is as follows:

automountd  < -Tnv >  < -D name=value >

Table 9.12 describes the syntax options for the automountd command.

Table 9.12. automountd Command Syntax

Option

Description

-T

Displays each remote procedure call (RPC) to standard output. You use this option for troubleshooting.

-n

Disables browsing on all AutoFS nodes.

-v

Logs all status messages to the console.

-D <name>=<value>

Substitutes value for the automount map variable indicated by name. The default value for the automount map is /etc/auto_master.


The automountd daemon is completely independent from the automount command. Because of this separation, it is possible to add, delete, or change map information without first having to stop and start the automountd daemon process.

When AutoFS runs, automount and automountd initiate at startup time from the svc:/system/filesystem/autofs service identifier. If a request is made to access a file system at an AutoFS mount point, the system goes through the following steps:

1.
AutoFS intercepts the request.

2.
AutoFS sends to the automountd daemon a message for the requested file system to be mounted.

3.
automountd locates the file system information in a map and performs the mount.

4.
AutoFS allows the intercepted request to proceed.

5.
AutoFS unmounts the file system after a period of inactivity.

Note

Automatic, Not Manual, Mounts Mounts 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, and this can result in possible inconsistency. A restart clears all AutoFS mount points.


To see who might be using a particular NFS mount, you use the showmount command. The syntax for showmount is shown here:

showmount <options>

The options for the showmount command are described in Table 9.13.

Table 9.13. showmount Command Syntax

Option

Description

-a

Prints all the remote mounts in the format hostname : directory.hostname is the name of the client, and directory is the root of the file system that has been mounted.

-d

Lists directories that have been remotely mounted by clients.

-e

Prints the list of shared file systems.


The following example illustrates the use of showmount to display file systems currently mounted from remote systems. On the NFS server named neptune, you could enter the following command:

showmount -a

The system would display the following information:

apollo:/export/home/neil

showmount says that the remote host, apollo, is currently mounting /export/home/neil on this server.

AutoFS Maps

The behavior of the automounter is governed by its configuration files, called maps. AutoFS searches maps to navigate its way through the network. Map files contain information, such as the location of other maps to be searched or the location of a user's home directory, for example.

There are three types of automount maps: the master map, the direct map, and the indirect map. Each of these is described in the following sections.

Master Maps

To start the navigation process, the automount command reads the master map at system startup. This map is what tells the automounter about map files and mount points. The master map lists all direct and indirect maps and their associated directories.

The master map, which is in the /etc/auto_master file, associates a directory with a map. The master map is a list that specifies all the maps that AutoFS should check. The following example shows what an auto_master file could contain:

# Master map for automounter
#
 +auto_master
 /net   -hosts    -nosuid,nobrowse
 /home  auto_home -nobrowse

This example shows the default auto_master file. The lines that begin with # are comments. The line that contains +auto_master specifies the AutoFS NIS table map, which is explained in Chapter 12, "Naming Services." Each line thereafter in the master map, /etc/auto_master, has the following syntax:

<mount-point> <map-name> <mount-options>

Each of these fields is described in Table 9.14.

Table 9.14. /etc/auto_master Fields

Field

Description

mount-point

The full (absolute) pathname of a directory that is used as the mount point. If the directory does not exist, AutoFS creates it, if possible. If the directory does exist and is not empty, mounting it hides its contents. In that case, AutoFS issues a warning. Using the notation /- as a mount point indicates that a direct map with no particular mount point is associated with the map.

map-name

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 specified in the name service switch configuration file (/etc/nsswitch.conf). Name service switches are described in Chapter 12.

mount-options

An optional comma-separated list of options that apply to the mounting of the entries specified in map-name, unless the entries list other options. Options for each specific type of file system are listed in Table 9.10. For NFS-specific mount points, the bg (background) and fg (foreground) options do not apply.


Note

Map Format A line that begins with a pound sign (#) is a comment, and everything that follows it until the end of the line is ignored. To split long lines into shorter ones, you can put a backslash (\) at the end of the line. The maximum number of characters in an entry is 1,024.


Every Solaris installation comes with a master map, called /etc/auto_master, that has the default entries shown in Table 9.14. Without any changes to the generic system setup, clients should be capable of accessing remote file systems through the /net mount point. The following entry in /etc/auto_master allows this to happen:

/net   -hosts   -nosuid,nobrowse

For example, let's say that you have an NFS server named apollo that has the /export file system exported. Another system, named zeus, exists on the network. This system has the default /etc/auto_master file; by default, it has a directory named /net. If you type the following, the command comes back showing that the directory is emptynothing is in it:

ls /net

Now type this:

ls /net/apollo

The system responds with this:

export

Why was the /net directory empty the first time you issued the ls command? When you issued ls /net/apollo, why did it find a subdirectory? This is the automounter in action. When you specified /net with a hostname, automountd looked at the map filein this case, /etc/hostsand found apollo and its IP address. It then went to apollo, found the exported file system, and created a local mount point for /net/apollo/export. It also added this entry to the /etc/mnttab table:

-hosts  /net/apollo/export  autofs  nosuid,nobrowse,ignore,nest,\
dev=2b80005 941812769

This entry in the /etc/mnttab table is referred to as a trigger node (because changing to the specified directory, the mount of the file system is "triggered").

If you enter mount, as follows, you won't see anything mounted at this point:

mount

The system responds with this:

/ on /dev/dsk/c0t3d0s0 read/write/setuid/largefiles on \
Mon Aug  8 09:45:21 2005
/usr on /dev/dsk/c0t3d0s6 read/write/setuid/largefiles on \
Mon Aug  8 09:45:21 2005
/proc on /proc read/write/setuid on Mon Aug  8 09:45:21 2005
/dev/fd on fd read/write/setuid on Mon Aug  8 09:45:21 2005
/export on /dev/dsk/c0t3d0s3 setuid/read/write/largefiles on \
Mon Aug  8 09:45:24 2005
/export/swap on /dev/dsk/c0t3d0s4 setuid/read/write/largefiles on \
Mon Aug  8 09:45:24 \ 2005
/tmp on swap read/write on Mon Aug  8 09:45:24 2005

Now type this:

ls /net/apollo/export

You should have a bit of a delay while automountd mounts the file system. The system then responds with this:

files   lost+found

The files listed are files located on apollo, in the /export directory. If you enter mount, you see a file system mounted on apollo that wasn't listed before:

mount
/ on /dev/dsk/c0t3d0s0 read/write/setuid/largefiles on \
Mon Aug  8 09:45:21 2005
/usr on /dev/dsk/c0t3d0s6 read/write/setuid/largefiles on \
Mon Aug  8 09:45:21 2005
/proc on /proc read/write/setuid on Mon Aug  8 09:45:21 2005
/dev/fd on fd read/write/setuid on Mon Aug  8 09:45:21 2005
/export on /dev/dsk/c0t3d0s3 setuid/read/write/largefiles on \
Mon Aug  8 09:45:24 2005
/export/swap on /dev/dsk/c0t3d0s4 setuid/read/write/largefiles on \
Mon Aug  8 09:45:24 \ 2005
/tmp on swap read/write on Mon Aug  8 09:45:24 2005
/net/apollo/export on apollo:/export nosuid/remote on \
Fri Aug 12 09:48:03 2005

The automounter automatically mounted the /export file system that was located on apollo. Now look at the /etc/mnttab file again, and you will see additional entries:

more /etc/mnttab
/dev/dsk/c0t3d0s0   /       ufs  rw,suid,dev=800018,largefiles  941454346
/dev/dsk/c0t3d0s6   /usr    ufs  rw,suid,dev=80001e,largefiles  941454346
/proc   /proc   proc    rw,suid,dev=2940000     941454346
fd      /dev/fd fd      rw,suid,dev=2a00000     941454346
/dev/dsk/c0t3d0s3   /export ufs  suid,rw,largefiles,dev=80001b  941454349
/dev/dsk/c0t3d0s4       /export/swap    ufs     suid,rw,largefiles,\
dev=80001c 941454349
swap    /tmp    tmpfs   dev=1   941454349
-hosts  /net    autofs  ignore,indirect,nosuid,nobrowse,dev=2b80001  \
   941454394
auto_home       /home   autofs  ignore,indirect,nobrowse,dev=2b80002  \
  941454394
-xfn    /xfn    autofs  ignore,indirect,dev=2b80003     941454394
sparcserver:vold(pid246)      /vol    nfs     ignore,noquota,dev=2b40001\
 941454409
-hosts  /net/apollo/export     autofs  nosuid,nobrowse,ignore,nest,\
dev=2b80005  941812769
apollo:/export /net/apollo/export     nfs     nosuid,dev=2b40003 \
941813283

If the /net/apollo/export directory is accessed, the AutoFS service completes the process, with these steps:

1.
It pings the server's mount service to see if it's alive.

2.
It mounts the requested file system under /net/apollo/export. Now the /etc/mnttab file contains the following entries:

-hosts  /net/apollo/export    autofs nosuid,nobrowse,ignore,nest,\
dev=2b80005  941812769
apollo:/export /net/apollo/export     nfs     nosuid,dev=2b40003 \
941813283

Because the automounter lets all users mount file systems, root access is not required. AutoFS also provides for automatic unmounting of file systems, so there is no need to unmount them when you are done.

Direct Maps

A direct map lists a set of unrelated mount points that might be spread out across the file system. A complete path (for example, /usr/local/bin, /usr/man) is listed in the map as a mount point. A good example of where to use a direct mount point is for /usr/man. The /usr directory contains many other directories, such as /usr/bin and /usr/local; therefore, it cannot be an indirect mount point. If you used an indirect map for /usr/man, the local /usr file system would be the mount point, and you would cover up the local /usr/bin and /usr/etc directories when you established the mount. A direct map lets the automounter complete mounts on a single directory entry such as /usr/man, and these mounts appear as links with the name of the direct mount point.

A direct map is specified in a configuration file called /etc/auto_direct. With a direct map, there is a direct association between a mount point on the client and a directory on the server. A direct map has a full pathname and indicates the relationship explicitly. This is a typical /etc/auto_direct map:

/usr/local     -ro
/share ivy:/export/local/share
/src   ivy:/export/local/src
/usr/man     -ro       apollo:/usr/man zeus:/usr/man neptune:/usr/man
/usr/game    -ro       peach:/usr/games
/usr/spool/news     -ro       jupiter:/usr/spool/news saturn:/var/spool/news

Note

Map Naming The direct map name /etc/auto_direct is not a mandatory name; it is used here as an example of a direct map. The name of a direct map must be added to the /etc/auto_master file, but it can be any name you choose, although it should be meaningful to the system administrator.


Lines in direct maps have the following syntax:

<key> <mount-options> <location>

The fields of this syntax are described in Table 9.15.

Table 9.15. Direct Map Fields

Field

Description

key

Indicates the pathname of the mount point in a direct map. This pathname specifies the local directory on which to mount the NFS.

mount-options

Indicates the options you want to apply to this particular mount. These options, which are listed in Table 9.10, are required only if they differ from the map default options specified in the /etc/auto_master file. There is no concatenation of options between the automounter maps. Any options added to an automounter map override all the options listed in previously searched maps. For instance, options included in the auto_master map would be overwritten by corresponding entries in any other map.

location

Indicates the remote location of the file system, specified as server:pathname. More than one location can be specified. pathname should not include an automounted mount point; it 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.


In the previous example of the /etc/auto_direct map file, the mount points, /usr/man and /usr/spool/news, list more than one location:

/usr/man       -ro    apollo:/usr/man zeus:/usr/man neptune:/usr/man
/usr/spool/news        -ro    jupiter:/usr/spool/news saturn:/var/spool/news

Multiple locations, such as those shown here, are used for replication, or failover. For the purposes of failover, a file system can be called a replica if each file is the same size and it is the same type of file system. Permissions, creation dates, and other file attributes are not a consideration. If the file size or the file system types are different, the remap fails and the process hangs until the old server becomes available.

Replication makes sense only if you mount a file system that is read-only because you must have some control over the locations of files that you write or modify. You don't want to modify one server's files on one occasion and, minutes later, modify the "same" file on another server. The benefit of replication is that the best available server is used automatically, without any effort required by the user.

If the file systems are configured as replicas, the clients have the advantage of using failover. Not only is the best 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 the manual (man) pages. In a large network, more than one server can export the current set of man pages. Which server you mount them from doesn't matter, as long as the server is running and exporting its file systems. In the previous example, multiple mount locations are expressed as a list of mount locations in the map entry. With multiple mount locations specified, you could mount the man pages from the apollo, zeus, or neptune servers. The best server depends on a number of factors, including the number of servers supporting a particular NFS protocol level, the proximity of the server, and weighting. The process of selecting a server goes like this:

  1. During the sorting process, a count of the number of servers supporting the NFS version 2, 3, and 4 protocols is done. The protocol supported on the most servers is the protocol that is supported by default. This provides the client with the maximum number of servers to depend on. If version 3 servers are most abundant, the sorting process becomes more complex because they will be chosen as long as a version 2 server on the local subnet is not being ignored. Normally servers on the local subnet are given preference over servers on a remote subnet. A version 2 server on the local subnet can complicate matters because it could be closer than the nearest version 3 server. If there is a version 2 server on the local subnet, and the closest version 3 server is on a remote subnet, the version 2 server is given preference. This is checked only if there are more version 3 servers than version 2 servers. If there are more version 2 servers than version 3 servers, only a version 2 server is selected.

  2. After the largest subset of servers that have the same protocol version is found, that server list is sorted by proximity. Servers on the local subnet are given preference over servers on a remote subnet. The closest server is given preference, which reduces latency and network traffic. If several servers are supporting the same protocol on the local subnet, the time to connect to each server is determined, and the fastest time is used.

    You can influence the selection of servers at the same proximity level by adding a numeric weighting value in parentheses after the server name in the AutoFS map. Here's an example:

    /usr/man -ro apollo,zeus(1),neptune(2):/usr/man

    Servers without a weighting have a value of 0, which makes them the most likely servers to be selected. The higher the weighting value is, the less chance the server has of being selected. All other server-selection factors are more important than weighting. Weighting is considered only in selections between servers with the same network proximity.

With failover, the sorting is checked once at mount time, to select one server from which to mount, and again if the mounted server becomes unavailable. Failover is particularly useful in a large network with many subnets. AutoFS chooses the nearest server and therefore confines NFS network traffic to a local network segment. In servers with multiple network interfaces, AutoFS lists the hostname associated with each network interface as if it were a separate server. It then selects the nearest interface to the client.

In the following example, you set up a direct map for /usr/local on zeus. Currently, zeus has a directory called /usr/local with the following directories:

ls /usr/local

The following local directories are displayed:

bin   etc   files   programs

If you set up the automount direct map, you can see how the /usr/local directory is overwritten by the NFS mount. Follow the procedure shown in Step by Step 9.6.

Step By Step 9.6: Creating a Direct Map

1.
Add the following entry in the master map file called /etc/auto_master:

/-   /etc/auto_direct

2.
Create the direct map file called /etc/auto_direct with the following entry:

/usr/local   zeus:/usr/local

3.
Because you're modifying a direct map, run automount to reload the AutoFS tables, as follows:

# automount

If you have access to the /usr/local directory, the NFS mount point is established by using the direct map you have set up. The contents of /usr/local have changed because the direct map has covered up the local copy of /usr/local:

ls /usr/local

You should see the following directories listed:

fasttrack   answerbook


Note

Overlay Mounting The local contents of /usr/local have not been overwritten. After the NFS mount point is unmounted, the original contents of /usr/local are redisplayed.


If you enter the mount command, you see that /usr/local is now mounted remotely from zeus:

mount
/ on /dev/dsk/c0t3d0s0 read/write/setuid/largefiles on \
Mon Aug 8 09:45:21 2005
/usr on /dev/dsk/c0t3d0s6 read/write/setuid/largefiles on \
Mon Aug 8 09:45:21 2005
/proc on /proc read/write/setuid on Mon Aug 8 09:45:21 2005
/dev/fd on fd read/write/setuid on Mon Aug 8 09:45:21 2005
/export on /dev/dsk/c0t3d0s3 setuid/read/write/largefiles on \
Mon Aug 8 09:45:24 2005
/export/swap on /dev/dsk/c0t3d0s4 setuid/read/write/largefiles on \
Mon Aug 8 09:45:24 2005
/tmp on swap read/write on Mon Aug 8 09:45:24 2005
/usr/local on zeus:/usr/local read/write/remote on \
Sat Aug 13 08:06:40 2005

Indirect Maps

Indirect maps are the simplest and most useful AutoFS maps. An indirect map uses a key's substitution value 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, from anywhere on the network. The following entry in the /etc/auto_master file is an example of an indirect map:

/share      /etc/auto_share

With this entry in the /etc/auto_master file, /etc/auto_share is the name of the indirect map file for the mount point /share. For this entry, you need to create an indirect map file named /etc/auto_share, which would look like this:

# share directory map for automounter
 #
 ws          neptune:/export/share/ws

If the /share directory is accessed, the AutoFS service creates a trigger node for /share/ws, and the following entry is made in the /etc/mnttab file:

-hosts  /share/ws     autofs  nosuid,nobrowse,ignore,nest,dev=###

If the /share/ws directory is accessed, the AutoFS service completes the process with these steps:

1.
It pings the server's mount service to see if it's alive.

2.
It 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=###
neptune:/export/share/ws /share/ws   nfs   nosuid,dev=####  #####

Lines in indirect maps have the following syntax:

<key> <mount-options> <location>

The fields in this syntax are described in Table 9.16.

Table 9.16. Indirect Map Field Syntax

Field

Description

key

A simple name (with no slashes) in an indirect map.

mount-options

The options you want to apply to this particular mount. These options, which are described in Table 9.10, are required only if they differ from the map default options specified in the /etc/auto_master file.

location

The remote location of the file system, specified as server:pathname. More than one location can be specified. pathname should not include an automounted mount point; it 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.


For example, say an indirect map is being used with user home directories. As users log in to several different systems, their home directories are not always local to the system. It's convenient for the users to use the automounter to access their home directories, regardless of what system they're logged in to. To accomplish this, the default /etc/auto_master map file needs to contain the following entry:

/home      /etc/auto_home        -nobrowse

/etc/auto_home is the name of the indirect map file that contains the entries to be mounted under /home. A typical /etc/auto_home map file might look like this:

more /etc/auto_home
 dean                   willow:/export/home/dean
 william                cypress:/export/home/william
 nicole                 poplar:/export/home/nicole
 glenda                 pine:/export/home/glenda
 steve                  apple:/export/home/steve
 burk                   ivy:/export/home/burk
 neil    -rw,nosuid     peach:/export/home/neil

Note

Indirect Map Names As with direct maps, the actual name of an indirect map is up to the system administrator, but a corresponding entry must be placed in the /etc/auto_master file, and the name should be meaningful to the system administrator.


Now assume that the /etc/auto_home map is on the host oak. If user neil has an entry in the password database that specifies his home directory as /home/neil, whenever he logs in to computer oak, AutoFS mounts the directory /export/home/neil, which resides on the computer peach. Neil's home directory is mounted read-write, nosuid. Anyone, including Neil, has access to this path from any computer set up with the master map referring to the /etc/auto_home map in this example. Under these conditions, user neil can run login, or rlogin, on any computer that has the /etc/auto_home map set up, and his home directory is mounted in place for him.

Another example of when to use an indirect map is when you want to make all project-related files available under a directory called /data that is to be common across all workstations at the site. Step by Step 9.7 shows how to do this.

Step By Step 9.7: Setting Up an Indirect Map

1.
Add an entry for the /data directory to the /etc/auto_master map file:

/data     /etc/auto_data    -nosuid

The auto_data map file, named /etc/auto_data, determines the contents of the /data directory.

2.
Add the -nosuid option as a precaution. The -nosuid option prevents users from creating files with the setuid or setgid bit set.

3.
Create the /etc/auto_data file and add entries to the auto_data map. The auto_data map is organized so that each entry describes a subproject. Edit /etc/auto_data to create a map that looks like the following:

compiler    apollo:/export/data/&
window      apollo:/export/data/&
files       zeus:/export/data/&
drivers     apollo:/export/data/&
man         zeus:/export/data/&
tools       zeus:/export/data/&

Note

Using the Entry Key The ampersand (&) at the end of each entry is an abbreviation for the entry key. For instance, the first entry is equivalent to the compiler apollo:/export/data/compiler.

Because the servers apollo and zeus view similar AutoFS maps locally, any users who log in to these computers find the /data file system as expected. These users are provided direct access to local files through loopback mounts instead of NFS mounts.

4.
Because you changed the /etc/auto_master map, the final step is to reload the AutoFS tables, as follows:

# automount

Now, if a user changes to the /data/compiler directory, the mount point to apollo:/export/data/compiler is created:

cd /data/compiler

5.
Type mount to see the mount point that was established:

mount

The system shows that /data/compiler is mapped to apollo:/export/data/compiler:

/data/compiler on apollo:/export/data/compiler read/write/remote \
on Fri Aug  12 17:17:02 2005

If the user changes to /data/tools, the mount point to zeus:/export/data/tools is created under the mount point /data/tools.


Note

Directory Creation There is no need to create the directory /data/compiler to be used as the mount point. AutoFS creates all the necessary directories before establishing the mount.


You can modify, delete, or add entries to maps to meet the needs of the environment. As applications (and other file systems that users require) change location, the maps must reflect those changes. You can modify AutoFS maps at any time. However, changes do not take place until the file system is unmounted and remounted. If a change is made to the auto_master map or to a direct map, those changes do not take place until the AutoFS tables are reloaded, as follows:

# automount

Exam Alert

Direct Versus Indirect Maps Remember the difference between direct and indirect maps. The /- entry in /etc/auto_master signifies a direct map because there is no mount point specified. This means that an absolute pathname is specified in the map. Indirect maps contain relative addresses, so the starting mount point, such as /home, appears in the /etc/auto_master enTRy for an indirect map.


When to Use automount

The most common and most advantageous use of automount is for mounting infrequently used file systems on an NFS client, such as online reference man pages. Another common use is accessing user home directories anywhere on the network. This works well for users who do not have a dedicated system and who tend to log in from different locations. Without the AutoFS service, to permit access, a system administrator has to create home directories on every system that the user logs in to. Data has to be duplicated everywhere, and it can easily become out of sync. You certainly don't want to create permanent NFS mounts for all user home directories on each system, so mounting infrequently used file systems on an NFS client is an excellent use for automount.

You also use automount if a read-only file system exists on more than one server. By using automount instead of conventional NFS mounting, you can configure the NFS client to query all the servers on which the file system exists and mount from the server that responds first.

You should avoid using automount to mount frequently used file systems, such as those that contain user commands or frequently used applications; conventional NFS mounting is more efficient in this situation. It is quite practical and typical to combine the use of automount with conventional NFS mounting on the same NFS client.


Previous Page
Next Page