NFS Administration Guide

Part III All About Autofs

This part of the manual discusses the autofs service and the procedures to use autofs.

Chapter 4 Autofs Administration

This chapter provides information on how to perform autofs administration tasks, such as modifying automounter maps, using the automounter to reach non-NFS type devices, and configuring maps.

Setting Up Autofs

This section includes procedures to start and stop the autofs service.

How to Start the Automounter

To enable the daemon without rebooting, become superuser and type the following command.

# /etc/init.d/autofs start

This starts the daemon.

How to Stop the Automounter

To disable the daemon without rebooting, become superuser and type the following command.

# /etc/init.d/autofs stop

Common Tasks and Procedures

This section describes some of the most common tasks you might encounter in your own environment. Recommended procedures are included for each scenario to help you configure autofs to best meet your clients' needs.

Note -

Use the Solstice System Management Tools or see the Solaris Naming Administration Guide to perform the tasks discussed in this section.

Administrative Tasks Involving Maps

The following list shows the different administrative tasks you might need to perform involving maps to change your autofs environment.

"How to Modify the Master Map"
"How to Modify Indirect Maps"
"How to Modify Direct Maps"
"Avoiding Mount-Point Conflicts "

Table 4-1 describes the types of maps and their uses.

Table 4-1 Types of autofs Maps and Their Uses


Type of Map	Use
Master	Associates a directory with a map
Direct	Directs autofs to specific file systems
Indirect	Directs autofs to reference-oriented file systems

Table 4-2 describes how to make changes to your autofs environment based on your name service.

Table 4-2 Map Maintenance


Name Service	Method
Local files	Text editor
NIS	`make` files
NIS+	`nistbladm`

Table 4-3 tells you when to run the automount command, depending on the modification you have made to the type of map. For example, if you have made an addition or a deletion to a direct map, you need to run the automount command on the local system to allow the change take effect; however, if you've modified an existing entry, you do not need to run the automount command for the change to take effect.

Table 4-3 When to Run the automount Command


Type of Map	Restart `automount`?
	Addition or Deletion	Modification
`auto_master`	`Y`	`Y`
`direct`	`Y`	`N`
`indirect`	`N`	`N`

Modifying the Maps

The following procedures require that you use NIS+ as your name service.

How to Modify the Master Map

Using the nistbladm command, make the changes you want to the master map.

See the Solaris Naming Administration Guide.

For each client, become superuser by typing su at a prompt and then the superuser password.

For each client, run the automount command to ensure the changes you made take effect.

Notify your users of the changes.

Notification is required so that the users can also run the automount command as superuser on their own computers.

The automount command consults the master map whenever it is run.

How to Modify Indirect Maps

Using the nistbladm command, make the changes you want to the indirect map.

See the Solaris Naming Administration Guide.

The change takes effect the next time the map is used, which is the next time a mount is done.

How to Modify Direct Maps

Using the nistbladm command, add or delete the changes you want to the direct map.

See the Solaris Naming Administration Guide.

If you added or deleted a mount-point entry in step 1, run the automount command.

Notify your users of the changes.

Notification is required so that the users can also run the automount command as superuser on their own computers.

Note -
If you only modify or change the contents of an existing direct map entry, you do not need to run the automount command.

For example, suppose you modify the auto_direct map so that the /usr/src directory is now mounted from a different server. If /usr/src is not mounted at this time, the new entry takes effect immediately when you try to access /usr/src. If /usr/src is mounted now, you can wait until the auto-unmounting takes place, then access it.

Note -
Because of the additional steps, and because they do not take up as much space in the mount table as direct maps, use indirect maps whenever possible. They are easier to construct, and less demanding on the computers' file systems.

Avoiding Mount-Point Conflicts

If you have a local disk partition mounted on /src and you also want to use the autofs service to mount other source directories, you might encounter a problem. If you specify the mount point /src, the service hides the local partition whenever you try to reach it.

You need to mount the partition somewhere else; for example, on /export/src. You would then need an entry in /etc/vfstab like:

/dev/dsk/d0t3d0s5 /dev/rdsk/c0t3d0s5 /export/src ufs 3 yes -

and this entry in auto_src:

terra		terra:/export/src

where terra is the name of the computer.

Accessing Non-NFS File Systems

Autofs can also mount files other than NFS files. Autofs mounts files on removable media, such as diskettes or CD-ROM. Normally, you would mount files on removable media using the Volume Manager. The following examples show how this mounting could be done through autofs. The Volume Manager and autofs do not work together, so these entries would not be used without first deactivating the Volume Manager.

Instead of mounting a file system from a server, you put the media in the drive and reference it from the map. If you want to access non-NFS file systems and you are using autofs, see the following procedures.

How to Access CD-ROM Applications With Autofs

Note -

Use this procedure if you are not using Volume Manager.

Specify the CD-ROM file system type as follows:

hsfs     -fstype=hsfs,ro     :/dev/sr0

The CD-ROM device you want to mount must appear as a name following a colon.

How to Access PC-DOS Data Diskettes With Autofs

Note -

Use this procedure if you are not using Volume Manager.

Specify the diskette file system type as follows:

 pcfs     -fstype=pcfs     :/dev/diskette

Accessing NFS File Systems Using CacheFS

The cache file system (CacheFS) is a generic nonvolatile caching mechanism that improves the performance of certain file systems by utilizing a small, fast, local disk.

You can improve the performance of the NFS environment by using CacheFS to cache data from an NFS file system on a local disk.

How to Access NFS File Systems Using CacheFS

Run the cfsadmin command to create a cache directory on the local disk.
# cfsadmin -c /var/cache

Add the cachefs entry to the appropriate automounter map.

For example, adding this entry to the master map caches all home directories:
/home auto_home -fstype=cachefs,cachedir=/var/cache,backfstype=nfs
Adding this entry to the auto_home map only caches the home directory for the user named rich:
rich -fstype=cachefs,cachedir=/var/cache,backfstype=nfs dragon:/export/home1/rich
Note -
Options that are included in maps that are searched later override options set in maps that are searched earlier. The last options found are the ones that are used. In the previous example, a specific entry added to the auto_home map only needs to include the options listed in the master maps if some of the options needed to be changed.

Customizing the Automounter

You can set up the automounter maps in several ways. The following tasks give detailed instructions on how to customize the automounter maps to provide an easy-to-use directory structure.

How to Set Up a Common View of `/home`

The ideal is for all network users to be able to locate their own, or anyone else's home directory under /home. This view should be common across all computers, whether client or server.

Every Solaris installation comes with a master map: /etc/auto_master.

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

A map for auto_home is also installed under /etc.

# Home directory map for autofs
#
+auto_home

Except for a reference to an external auto_home map, this map is empty. If the directories under /home are to be common to all computers, then do not modify this /etc/auto_home map. All home directory entries should appear in the name service files, either NIS or NIS+.

Note -

Users should not be permitted to run setuid executables from their home directories; without this restriction, any user could have superuser privileges on any computer.

How to Set Up `/home` With Multiple Home Directory File Systems

Install home directory partitions under /export/home.

If there are several partitions, install them under separate directories, for example, /export/home1, /export/home2, and so on.

Use the Solstice System Management Tools to create and maintain the auto_home map.

Whenever you create a new user account, type the location of the user's home directory in the auto_home map. Map entries can be simple, for example:
rusty dragon:/export/home1/& gwenda dragon:/export/home1/& charles sundog:/export/home2/& rich dragon:/export/home3/&
Notice the use of the & (ampersand) to substitute the map key. This is an abbreviation for the second occurrence of rusty in the following example.
rusty dragon:/export/home1/rusty
With the auto_home map in place, users can refer to any home directory (including their own) with the path /home/user, where user is their login name and the key in the map. This common view of all home directories is valuable when logging in to another user's computer. Autofs mounts your home directory for you. Similarly, if you run a remote windowing system client on another computer, the client program has the same view of the /home directory as you do on the computer providing the windowing system display.

This common view also extends to the server. Using the previous example, if rusty logs in to the server dragon, autofs there provides direct access to the local disk by loopback-mounting /export/home1/rusty onto /home/rusty.

Users do not need to be aware of the real location of their home directories. If rusty needs more disk space and needs to have his home directory relocated to another server, you need only change rusty's entry in the auto_home map to reflect the new location. Everyone else can continue to use the /home/rusty path.

How to Consolidate Project-Related Files Under `/ws`

Assume you are the administrator of a large software development project. You want to make all project-related files available under a directory called /ws. This directory is to be common across all workstations at the site.

Add an entry for the /ws directory to the site auto_master map, either NIS or NIS+.
/ws auto_ws -nosuid
The auto_ws map determines the contents of the /ws directory.

Add the -nosuid option as a precaution.

This option prevents users from running setuid programs that might exist in any workspaces.

Add entries to the auto_ws map.

The auto_ws map is organized so that each entry describes a subproject. Your first attempt yields a map that looks like the following:

compiler   alpha:/export/ws/&
windows    alpha:/export/ws/&
files      bravo:/export/ws/&
drivers    alpha:/export/ws/&
man        bravo:/export/ws/&
tools      delta:/export/ws/&

The ampersand (&) at the end of each entry is an abbreviation for the entry key. For instance, the first entry is equivalent to:

compiler		alpha:/export/ws/compiler

This first attempt provides a map that looks simple, but it turns out to be inadequate. The project organizer decides that the documentation in the man entry should be provided as a subdirectory under each subproject. Also, each subproject requires subdirectories to describe several versions of the software. You must assign each of these subdirectories to an entire disk partition on the server.

Modify the entries in the map as follows:

compiler \
    /vers1.0    alpha:/export/ws/&/vers1.0 \
    /vers2.0    bravo:/export/ws/&/vers2.0 \
    /man        bravo:/export/ws/&/man
windows \
    /vers1.0    alpha:/export/ws/&/vers1.0 \
    /man        bravo:/export/ws/&/man
files \
    /vers1.0    alpha:/export/ws/&/vers1.0 \
    /vers2.0    bravo:/export/ws/&/vers2.0 \
    /vers3.0    bravo:/export/ws/&/vers3.0 \
    /man        bravo:/export/ws/&/man
drivers \
    /vers1.0    alpha:/export/ws/&/vers1.0 \
    /man        bravo:/export/ws/&/man
tools \
    /           delta:/export/ws/&

Although the map now appears to be much larger, it still contains only the five entries. Each entry is larger because it contains multiple mounts. For instance, a reference to /ws/compiler requires three mounts for the vers1.0, vers2.0, and man directories. The backslash at the end of each line tells autofs that the entry is continued onto the next line. In effect, the entry is one long line, though line breaks and some indenting have been used to make it more readable. The tools directory contains software development tools for all subprojects, so it is not subject to the same subdirectory structure. The tools directory continues to be a single mount.

This arrangement provides the administrator with much flexibility. Software projects are notorious for consuming substantial amounts of disk space. Through the life of the project you might be required to relocate and expand various disk partitions. As long as these changes are reflected in the auto_ws map, the users do not need to be notified, as the directory hierarchy under /ws is not changed.

Because the servers alpha and bravo view the same autofs map, any users who log in to these computers can find the /ws name space as expected. These users are provided with direct access to local files through loopback mounts instead of NFS mounts.

How to Set Up Different Architectures to Access a Shared Name Space

You need to assemble a shared name space for local executables, and applications, such as spreadsheet tools and word-processing packages. The clients of this name space use several different workstation architectures that require different executable formats. Also, some workstations are running different releases of the operating system.

Create the auto_local map with the nistbladm command.

See the Solaris Naming Administration Guide.

Choose a single, site-specific name for the shared name space so that files and directories that belong to this space are easily identifiable.

For example, if you choose /usr/local as the name, then the path /usr/local/bin is obviously a part of this name space.

For ease of user community recognition, create an autofs indirect map and mount it at /usr/local. Set up the following entry in the NIS+ (or NIS) auto_master map:
/usr/local auto_local -ro
Notice that the ro mount option implies that clients will not be able to write to any files or directories.

Export the appropriate directory on the server.

Include a bin entry in the auto_local map.

Your directory structure looks like this:
bin aa:/export/local/bin
To satisfy the need to serve clients of different architectures, references to the bin directory need to be directed to different directories on the server, depending on the clients' architecture type.

To serve clients of different architectures, change the entry by adding the autofs CPU variable.
bin aa:/export/local/bin/$CPU
Note -
For SPARCstation^TM clients, make executables available under /export/local/bin/sparc on the server. For x86 clients, use /export/local/bin/i386.

How to Support Incompatible Client Operating System Versions

Combine the architecture type with a variable that determines the operating system type of the client.

The autofs OSREL variable can be combined with the CPU variable to form a name that determines both CPU type and OS release.

Create the following map entry.
bin aa:/export/local/bin/$CPU$OSREL

For SPARC clients running version 5.6 of the operating system, you need to export /export/local/bin/sparc5.6 from the server and create similar entries for other releases. Because operating systems attempt to preserve backward compatibility with executable formats, assume that the OS release is not a factor and eliminate it from future examples.

So far, you have set up an entry for a single server aa. In a large network, you want to replicate these shared files across several servers. Each server should have a close network proximity to the clients it serves so that NFS traffic is confined to local network segments.

How to Replicate Shared Files Across Several Servers

The best way to share replicated file systems that are read-only is to use failover. See "Client-Side Failover" for a discussion of failover.

Modify the entry to create the list of all replica servers as a comma-separated list:

bin     aa,bb,cc,dd:/export/local/bin/$CPU

Autofs chooses the nearest server. If a server has several network interfaces, then list each interface. Autofs chooses the nearest interface to the client, avoiding unnecessary routing of NFS traffic.

How to Apply Security Restrictions

Create the following entry in the name service auto_master file, either NIS or NIS+:

/home     auto_home     -nosuid

The nosuid option prevents users from creating files with the setuid or setgid bit set.

This entry overrides the entry for /home in a generic local /etc/auto_master file (see the previous example) because the +auto_master reference to the external name service map occurs before the /home entry in the file. If the entries in the auto_home map include mount options, then the nosuid option is overwritten, so either no options should be used in the auto_home map or the nosuid option must be included with each entry.

Note -

Do not mount the home directory disk partitions on or under /home on the server.

How to Use a Public File Handle With Autofs

Create an entry like the following:

/usr/local     -ro,public    bee:/export/share/local

The public option forces the public handle to be used. If the NFS server does not support a public file handle, the mount will fail.

How to Use NFS URLs With Autofs

Create an entry like the following:

/usr/local     -ro    nfs://bee/export/share/local

The service tries to use the public file handle on the NFS server, but if the server does not support a public file handle then the MOUNT protocol is used.

Disabling Autofs Browsability

Starting with the Solaris 2.6 release, the default version of /etc/auto_master that is installed has the -nobrowse option added to the entries for /home and /net. In addition, the upgrade procedure adds the -nobrowse option to the /home and /net entries in /etc/auto_master if these entries have not been modified. However, it might be necessary to make these changes manually or to turn off browsability for site-specific autofs mount points after the installation.

You can turn off the browsability feature in several ways. Disable it using a command-line option to the automountd daemon, which completely disables autofs browsability for the client. Or disable it for each map entry on all clients using the autofs maps in either a NIS or NIS+ name space, or for each map entry on each client, using local autofs maps if no network-wide name space is being used.

How to Completely Disable Autofs Browsability on a Single NFS Client

Add the -n option to the startup script.

As root, edit the /etc/init.d/autofs script and add the -n option to the line that starts the automountd daemon:
/usr/lib/autofs/automountd -n \ < /dev/null > /dev/console 2>&1 # start daemon

Restart the autofs service.

# /etc/init.d/autofs stop
# /usr/init.d/autofs start

How to Disable Autofs Browsability for All Clients

To disable browsability for all clients, you must employ a name service such as NIS or NIS+. Otherwise, you need to manually edit the automounter maps on each client. In this example, the browsability of the /home directory is disabled. You must follow this procedure for each indirect autofs node that needs to be disabled.

Add the -nobrowse option to the /home entry in the name service auto_master file.
/home auto_home -nobrowse

On all clients: run the automount command.

The new behavior takes effect after running the automount command on the client systems or after a reboot.
# /usr/sbin/automount

How to Disable Autofs Browsability on an NFS Client

In this example, browsability of the /net directory is disabled. The same procedure can be used for /home or any other autofs mount points.

Check the automount entry in /etc/nsswitch.conf.

For local file entries to take precedence, the entry in the name service switch file should list files before the name service. For example:
automount: files nisplus
This is the default configuration in a standard Solaris installation.

Check the position of the +auto_master entry in /etc/auto_master.

For additions to the local files to take precedence over the entries in the name space, the +auto_master entry must be moved below /net:
# Master map for automounter # /net -hosts -nosuid /home auto_home /xfn -xfn +auto_master
A standard configuration places the +auto_master entry at the top of the file. This prevents any local changes from being used.

Add the -nobrowse option to the /net entry in the /etc/auto_master file.
/net -hosts -nosuid,nobrowse

On all clients: run the automount command.

The new behavior takes effect after running the automount command on the client systems or after a reboot.
# /usr/sbin/automount

Troubleshooting Autofs

Occasionally, you might encounter problems with autofs. This section should make the problem-solving process easier. It is divided into two subsections.

This section presents a list of the error messages that autofs generates. The list is divided into two parts:

Error messages generated by the verbose (-v) option of automount
Error messages that might appear at any time

Each error message is followed by a description and probable cause of the message.

When troubleshooting, start the autofs programs with the verbose (-v) option, otherwise, you might experience problems without knowing why.

The following paragraphs are labeled with the error message you are likely to see if autofs fails, and a description of the possible problem.

Error Messages Generated by `automount -v`

bad key key in direct map mapname

While scanning a direct map, autofs has found an entry key without a prefixed /. Keys in direct maps must be full path names.

bad key key in indirect map mapname

While scanning an indirect map, autofs has found an entry key containing a /. Indirect map keys must be simple names--not path names.

can't mount server:pathname: reason

The mount daemon on the server refuses to provide a file handle for server:pathname. Check the export table on server.

couldn't create mount point mountpoint: reason

Autofs was unable to create a mount point required for a mount. This most frequently occurs when attempting to hierarchically mount all of a server's exported file systems. A required mount point can exist only in a file system that cannot be mounted (it cannot be exported) and it cannot be created because the exported parent file system is exported read-only.

leading space in map entry entry text in mapname

Autofs has discovered an entry in an automount map that contains leading spaces. This is usually an indication of an improperly continued map entry, for example:

fake
/blat   		frobz:/usr/frotz

In this example, the warning is generated when autofs encounters the second line because the first line should be terminated with a backslash (\).

mapname: Not found

The required map cannot be located. This message is produced only when the -v option is used. Check the spelling and path name of the map name.

remount server:pathname on mountpoint: server not responding

Autofs has failed to remount a file system it previously unmounted.

WARNING: mountpoint already mounted on

Autofs is attempting to mount over an existing mount point. This means there is an internal error in autofs (an anomaly).

Miscellaneous Error Messages

dir mountpoint must start with '/': Automounter mount point must be given as full path name. Check the spelling and path name of the mount point.
hierarchical mountpoints: pathname1 and pathname2: Autofs does not allow its mount points to have a hierarchical relationship. An autofs mount point must not be contained within another automounted file system.
host server not responding: Autofs attempted to contact server, but received no response.
hostname: exports: rpc_err: Error getting export list from hostname. This indicates a server or network problem.
map mapname, key key: bad: The map entry is malformed, and autofs cannot interpret it. Recheck the entry; perhaps there are characters in it that need escaping.
mapname: nis_err: Error in looking up an entry in a NIS map. This can indicate NIS problems.
mount of server:pathname on mountpoint:reason: Autofs failed to do a mount. This can indicate a server or network problem.
mountpoint: Not a directory: Autofs cannot mount itself on mountpoint because it is not a directory. Check the spelling and path name of the mount point.
nfscast: cannot send packet: reason: Autofs cannot send a query packet to a server in a list of replicated file system locations.
nfscast: cannot receive reply: reason: Autofs cannot receive replies from any of the servers in a list of replicated file system locations.
nfscast: select: reason: All these error messages indicate problems attempting to ping servers for a replicated file system. This can indicate a network problem.
pathconf: no info for server:pathname: Autofs failed to get pathconf information for pathname (see the fpathconf(2) man page).
pathconf: server: server not responding: Autofs is unable to contact the mount daemon on server that provides the information to pathconf().

Other Errors With Autofs

If the /etc/auto* files have the execute bit set, then the automounter tries to execute the maps, which creates messages like:

/etc/auto_home: +auto_home: not found

In this case, the auto_home file has incorrect permissions. Each entry in the file will generate an error message much like this one. The permissions to the file should be reset by typing the following command:

# chmod 644 /etc/auto_home

Chapter 5 About Autofs

This chapter describes the parts of the autofs service and gives more detailed information about the autofs maps.

Autofs Programs

Two programs support the autofs service. Both are run when a system is booted, but only automountd is persistent.

`automount`

This command installs autofs mount points and associates the information in the automaster files with each mount point. The syntax of the command is:

automount [ -t duration ] [ -v ]

where -t duration sets the time, in seconds, that a file system is to remain mounted, and -v selects the verbose mode. Running this command in the verbose mode allows for easier troubleshooting.

If not specifically set, the value for duration is set to 5 minutes. In most circumstances this is a good value; however, on systems that have many automounted file systems, you might need to increase the duration value. In particular, if a server has many users active, checking the automounted file systems every five minutes can be inefficient. Checking the autofs file systems every 1800 seconds (or 30 minutes) could be more optimal. By not unmounting the file systems every 5 minutes, it is possible that /etc/mnttab, which is checked by df, can become very large. The output from df can be filtered by using the -F option (see the df(1M) man page) or by using egrep to help fix this problem.

Another factor to consider is that adjusting the duration also changes how quickly changes to the automounter maps will be reflected. Changes will not be seen until the file system is unmounted. Refer to "Modifying the Maps" for instructions on how to modify automounter maps.

`automountd`

This daemon handles the mount and unmount requests from the autofs service. The syntax of the command is:

automountd [ -Tnv ] [ -D name=value ]

where -T selects to display each RPC call to standard output, -n disables browsing on all autofs nodes, -v selects to log all status messages to the console, and -D name=value substitutes value for the automount map variable indicated by name. The default value for the automount map is /etc/auto_master. Use the -T option for troubleshooting.

Autofs Maps

Autofs uses three types of maps:

Master map
Direct maps
Indirect maps

Master Map

The auto_master map associates a directory with a map. It is a master list specifying all the maps that autofs should check. The example below shows what an auto_master file could contain.

Example 5-1 Sample `/etc/auto_master` File

# Master map for automounter 
# 
+auto_master 
/net            -hosts           -nosuid,nobrowse 
/home           auto_home        -nobrowse 
/xfn            -xfn
/-              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

mount-point is the full (absolute) path name of a directory. If the directory does not exist, autofs creates it if possible. If the directory exists and is not empty, mounting on it hides its contents. In this case, autofs issues a warning.

The notation /- as a mount point indicates that the map in question is a direct map, and no particular mount point is associated with the map as a whole.

map-name

map-name is the map 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 using the search specified in the name service switch configuration file (/etc/nsswitch.conf). Special maps are also used for /net and /xfn (see "Mount Point /net" and "Mount Point /xfn").

mount-options

mount-options is an optional, comma-separated list of options that apply to the mounting of the entries 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 example, see the mount_nfs(1M) man page for NFS specific mount options). For NFS specific mount points, the bg (background) and fg (foreground) options do not apply.

A line beginning with # is a comment. Everything 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.

Mount Point `/home`

The mount point /home is the directory under which the entries 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. These defaults can be overridden by entries in the NIS auto.master map or NIS+ auto_master table, 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 map -hosts. This is a built-in map that uses only the hosts database. For example, if the computer gumbo is in the hosts database and it exports any of its file systems, the command:

%cd /net/gumbo

changes the current directory to the root directory of the computer gumbo. Notice that autofs can mount only the exported file systems of host gumbo, that is, those on a server available to network users as opposed to those on a local disk. Therefore, all the files and directories on gumbo might not be available through /net/gumbo.

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 use /net.

Note -

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.

Mount Point `/xfn`

This mount point provides the autofs directory structure for the resources that are shared through the FNS name space (see the Solaris Naming Setup and Configuration Guide for more information about FNS).

Direct Maps

A direct map is an automount point. With a direct map, there is a direct association 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. This is a typical /etc/auto_direct map:

/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

Lines in direct maps have the following syntax:

key [ mount-options ] location

key

key is the path name of the mount point in a direct map.

mount-options

mount-options are the options you want to apply to this particular mount. They are required only if they 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_cachefs(1M) man page for CacheFS specific mount options).

location

location is the location of the file system, specified (one or more) as server:pathname for NFS file systems or :devicename for High Sierra file systems (HSFS).

Note -

The 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.

As in the master map, a line beginning 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, in their simplest form, the corresponding entries in /etc/vfstab (vfstab contains a list of all file systems to be mounted). An entry that appears in /etc/vfstab as:

dancer:/usr/local - /usr/local/tmp nfs - yes ro

appears in a direct map as:

/usr/local/tmp     -ro     dancer:/usr/local

Note -

There is no concatenation of options between the automounter maps. Any options added to an automounter map override all options listed in maps that are searched earlier. For instance, options included in the auto_master map would be overwritten by corresponding entries in any other map.

See "How Autofs Selects the Nearest Read-Only Files for Clients (Multiple Locations)" for other important features associated with this type of map.

Mount Point `/-`

In Example 5-1, the mount point /- tells autofs not to associate the entries in auto_direct with any specific mount point. Indirect maps use mount points defined in the auto_master file. Direct maps use mount points specified in the named map. (Remember, in a direct map the key, or mount point, is a full path name.)

An NIS or NIS+ auto_master file can have only one direct map entry because the mount point must be a unique value in the name space. An auto_master file that is a local file can have any number of direct map entries, as long as entries are not duplicated.

Indirect 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, like 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

key is a simple name (no slashes) in an indirect map.

mount-options

The mount-options are the options you want to apply to this particular mount. They are required only if they 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 is the location of the file system, specified (one or more) as server:pathname.

Note -

The 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.

As in the master map, a line beginning 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 5-1 shows an auto_master map that contains the 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:

david                  willow:/export/home/david
rob                    cypress:/export/home/rob
gordon                 poplar:/export/home/gordon
rajan                  pine:/export/home/rajan
tammy                  apple:/export/home/tammy
jim                    ivy:/export/home/jim
linda    -rw,nosuid    peach:/export/home/linda

As an example, assume that the previous map is on host oak. If user linda has an entry in the password database specifying her home directory as /home/linda, then whenever she logs in to computer oak, autofs mounts the directory /export/home/linda residing on the computer peach. Her home directory is mounted read-write, nosuid.

Assume the following conditions occur: User linda's home directory is listed in the password database as /home/linda. Anybody, including Linda, has access to this path from any computer set up with the master map referring to the map in the previous example.

Under these conditions, user linda can run login or rlogin on any of these computers and have her home directory mounted in place for her.

Furthermore, now Linda can also type the following command:

% cd ~david

autofs mounts David's home directory for her (if all permissions allow).

Note -

There is no concatenation of options between the automounter maps. Any options added to an automounter map override all options listed in maps that are searched earlier. For instance, options included in the auto_master map are overwritten 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 accomplish this. With NIS, make the changes on the NIS master server and propagate the relevant databases to the slave servers. On a network running NIS+, propagating the relevant databases to the slave servers is done automatically after the changes are made.

How Autofs Works

Autofs is a client-side service that automatically mounts the appropriate file system. When a client attempts to access a file system that is not presently mounted, the autofs file system intercepts the request and calls automountd, to mount the requested directory. The automountd daemon locates the directory, mounts it within autofs, and replies. On receiving the reply, autofs allows the waiting request to proceed. Subsequent references to the mount are redirected by the autofs--no further participation is required by automountd, until the file system is automatically unmounted by autofs after a period of inactivity.

The components that work together to accomplish automatic mounting are:

The automount command
The autofs file system
The automountd daemon

The automount command, 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. They are points under which file systems are mounted in the future. These points are also known as trigger nodes.

After the autofs mounts are set up, they 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.

Starting with the Solaris 2.5 release, 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.

After initially mounting autofs mounts, the automount command is used to update autofs mounts as necessary, by comparing 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) and making the appropriate changes. This allows system administrators to change mount information within auto_master and have those changes used by the autofs processes without having to stop and restart 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 name space or local files.

This is a simplified overview of how autofs works:

The automount daemon automountd starts at boot time from the /etc/init.d/autofs script (See Figure 5-1). This script also runs the automount command, which reads the master map (see "How Autofs Starts the Navigation Process (Master Map)") and installs autofs mount points.

Figure 5-1 `/etc/init.d/autofs` Script Starts `automount`

Autofs is a kernel file system that supports automatic mounting and unmounting.

When a request is made to access a file system at an autofs mount point:

Autofs intercepts the request.
Autofs sends a message to the automountd for the requested file system to be mounted.
automountd 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.

Note -

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, resulting in possible inconsistency. A reboot clears all of the autofs mount points.

How Autofs Navigates Through the Network (Maps)

Autofs searches a series of maps to navigate its way 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, that is, network-wide equivalents of UNIX administration files. Maps are available locally or through a network name service like NIS or NIS+. You create maps to meet the needs of your environment using the Solstice System Management Tools. See "Modifying How Autofs Navigates the Network (Modifying Maps)".

How Autofs Starts the Navigation Process (Master Map)

The automount command reads the master map at system startup. Each entry in the master map is a direct or indirect map name, its path, and its mount options, as shown in Figure 5-2. The specific order of the entries is not important. automount compares entries in the master map with entries in the mount table to generate a current list.

Figure 5-2 Navigation Through the Master Map

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, but the final result changes with the mount point specified and the complexity of the maps. Starting with the Solaris 2.6 release, the mount process has also been changed to include the creation of the trigger nodes.

A 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
/xfn        -xfn
/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 can be seen in /etc/mnttab as an entry 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 with these steps:

Pings the server's mount service to see if it's alive

Mounts the requested file system under /share. Now /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=####    #####

Hierarchical Mounting

When multiple layers are defined in the automounter files, the mount process becomes more complex. If the /etc/auto_shared file from the previous example is expanded to contain:

# 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. Refer to "Autofs Unmounting" for an explanation of this limitation.

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 timeout. The failure to reinstall the trigger notes 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, 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 (Multiple Locations)

In the example of a direct map, which was:

/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 (three for the first, two for the second). This means any of the replicated locations can provide the same service to any user. This procedure makes sense only when you mount a file system that is read-only, as you must have some control over the locations of files you write or modify. You don't want to modify files on one server on one occasion and, minutes later, modify the "same" file on another server. The benefit is that the best available server is used automatically without any effort required by the user.

If the file systems are configured as replicas (see "What Is a Replicated File System?"), then 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. Failover is a new feature implemented in the Solaris 2.6 release.

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 manual pages. Which server you mount them from does not 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.

/usr/man -ro oak:/usr/man rose:/usr/man willow:/usr/man

Here 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 number of servers supporting a particular NFS protocol level, the proximity of the server, and weighting.

During the sorting process, a count of the number of servers supporting the NFS version 2 and NFS version 3 protocols is made. Whichever protocol is supported on the most servers becomes the protocol supported by default. This provides the client with the maximum number of servers to depend on.

Once the largest subset of servers with 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. Figure 5-3 illustrates server proximity.

Figure 5-3 Server Proximity

If several servers supporting the same protocol are on the local subnet, the time to connect to each server is determined and the fastest is used. The sorting can also be influenced by using weighting (see "Autofs and Weighting").

If version 3 servers are more abundant, the sorting process becomes more complex. Normally, servers on the local subnet are given preference over servers on a remote subnet. A version 2 server can complicate matters, as it might 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 preference is only checked if there are more version 3 servers than version 2 servers. If there are more version 2 servers, then only a version 2 server is selected.

With failover, the sorting is checked once at mount time to select one server from which to mount, and again anytime the mounted server becomes unavailable. Multiple locations are useful in an environment where individual servers might not export their file systems temporarily.

This feature 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, list the host name associated with each network interface as if it were a separate server. Autofs selects the nearest interface to the client.

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 (most likely to be selected). The higher the weighting value, the lower the chance the server will be 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 a Map Entry

You can create a client-specific variable by prefixing a dollar sign ($) to its name. This helps you to accommodate different architecture types accessing the same file system location. You can also use curly braces to delimit the name of the variable from appended letters or digits. Table 5-1 shows the predefined map variables.

Table 5-1 Predefined Map Variables


Variable	Meaning	Derived From	Example
`ARCH`	Architecture type	`uname -m`	`sun4`
`CPU`	Processor Type	`uname -p`	`sparc`
`HOST`	Host name	`uname -n`	`dinky`
`OSNAME`	Operating system name	`uname -s`	`SunOS`
`OSREL`	Operating system release	`uname -r`	`5.4`
`OSVERS`	Operating system version (version of the release)	`uname -v`	`FCS1.0`

You can use variables anywhere in an entry line except as a key. For instance, if you have a file server exporting 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 like the following:

/usr/local/bin	   -ro	server:/usr/local/bin/$CPU

Now the same entry for all clients applies to all architectures.

Note -

Most applications written for any of the sun4 architectures can run on all sun4 platforms, so the -ARCH variable is hardcoded to sun4 instead of sun4m or sun4c.

Maps That Refer to Other Maps

A map entry +mapname 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, then autofs treats the map name as a string of characters and uses the name service switch policy to find it. If the path name is an absolute path name, then automount looks for a local map of that name. If the map name starts with a dash (-), automount consults the appropriate built-in map, such as xfn or hosts.

This name service switch file contains an entry for autofs labeled as automount, which contains the order in which the name services are searched. The following file is an example of a name service switch file:

#
# /etc/nsswitch.nis:
#
# An example file that could be copied over to /etc/nsswitch.conf;
# it uses NIS (YP) in conjunction with files.
#
# "hosts:" and "services:" in this file are used only if the /etc/netconfig
# file contains "switch.so" as a nametoaddr library for "inet" transports.
# the following two lines obviate the "+" entry in /etc/passwd and /etc/group.
passwd:         files nis
group:          files nis

# consult /etc "files" only if nis is down.
hosts:          nis [NOTFOUND=return] files
networks:       nis [NOTFOUND=return] files
protocols:      nis [NOTFOUND=return] files
rpc:            nis [NOTFOUND=return] files
ethers:         nis [NOTFOUND=return] files
netmasks:       nis [NOTFOUND=return] files
bootparams:     nis [NOTFOUND=return] files
publickey:      nis [NOTFOUND=return] files
netgroup:       nis
automount:      files nis
aliases:        files nis
# for efficient getservbyname() avoid nis
services:       files nis

In this example, the local maps are searched before the NIS maps, so you can have a few entries in your local /etc/auto_home map for the most commonly accessed home directories, and 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. This means 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 included can be a local file (remember, only local files can contain + entries) or a built-in map:

+auto_home_finance      # NIS+ map
+auto_home_sales        # NIS+ map
+auto_home_engineering  # NIS+ map
+/etc/auto_mystuff      # local map
+auto_home              # NIS+ map
+-hosts                 # built-in hosts map

Note -

You cannot use + entries in NIS+ or NIS maps.

Executable Autofs Maps

You can create an autofs map that will execute some commands to generate the autofs mount points. You could benefit from using an executable autofs map 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 will need to be installed on each host. An executable map cannot be included in either the NIS or the NIS+ name service.

The executable map must have an entry in the auto_master file.

/execute    auto_execute

Here is an example of an 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:

% ls /execute/src

causes the /export1 file system from bee to be mounted.

Modifying How Autofs Navigates the Network (Modifying Maps)

You can modify, delete, or add entries to maps to meet the needs of your environment. As applications and other file systems that users require change their location, the maps must reflect those changes. You can modify autofs maps at any time. Whether your modifications take effect the next time automountd mounts a file system depends on which map you modify and what kind of modification you make.

Default Autofs Behavior With Name Services

Booting invokes autofs using the /etc/init.d/autofs script and checks for the master auto_master map (subject to the rules discussed subsequently).

Autofs uses the name service specified in the automount entry of the /etc/nsswitch.conf file. If NIS+ is specified, as opposed to local files or NIS, all map names are used as is. If NIS is selected and autofs cannot find a map that it needs, but finds a map name that contains one or more underscores, the underscores are changed to dots, which allows the old NIS file names to work. Then autofs looks up the map again, as shown in Figure 5-4.

Figure 5-4 How Autofs Uses the Name Service

The screen activity for this session would look like 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 it uses.

Autofs Reference

The rest of this chapter describes more advanced autofs features and topics.

Metacharacters

Autofs recognizes some characters as having a special meaning. Some are used for substitutions, some to protect other characters from the autofs map parser.

Ampersand (`&`)

If you have a map with many subdirectories specified, as in the following, consider using string substitutions.

john        willow:/home/john
mary        willow:/home/mary
joe         willow:/home/joe
able        pine:/export/able
baker       peach:/export/baker

You can use the ampersand character (&) to substitute the key wherever it appears. If you use the ampersand, the previous map changes to:

john        willow:/home/&
mary        willow:/home/&
joe         willow:/home/&
able        pine:/export/&
baker       peach:/export/&

You could also use key substitutions in a direct map, in situations like this:

/usr/man						willow,cedar,poplar:/usr/man

which you can also write as:

/usr/man						willow,cedar,poplar:&

Notice that the ampersand substitution uses the whole key string, so if the key in a direct map starts with a / (as it should), the slash is carried over, and you could not do, for example, the following:

/progs				&1,&2,&3:/export/src/progs

because autofs would interpret it as:

/progs 				/progs1,/progs2,/progs3:/export/src/progs

Asterisk (`*`)

You can use the universal substitute character, the asterisk (*), to match any key. You could mount the /export file system from all hosts through this map entry.

*						&:/export

Each ampersand is substituted by the value of any given key. Autofs interprets the asterisk as an end-of-file character.

Special Characters

If you have a map entry that contains special characters, you might have to mount directories whose names confuse the autofs map parser. The autofs parser is sensitive to names containing colons, commas, spaces, and so on. These names should be enclosed in double quotations, as in the following:

/vms    -ro    vmsserver: -  -  - "rc0:dk1 - "
/mac    -ro    gator:/ - "Mr Disk - "

Part III All About Autofs

Chapter 4 Autofs Administration

Setting Up Autofs

How to Start the Automounter

How to Stop the Automounter

Common Tasks and Procedures

Administrative Tasks Involving Maps

Modifying the Maps

How to Modify the Master Map

How to Modify Indirect Maps

How to Modify Direct Maps

Avoiding Mount-Point Conflicts

Accessing Non-NFS File Systems

How to Access CD-ROM Applications With Autofs

How to Access PC-DOS Data Diskettes With Autofs

Accessing NFS File Systems Using CacheFS

How to Access NFS File Systems Using CacheFS

Customizing the Automounter

How to Set Up a Common View of /home

How to Set Up /home With Multiple Home Directory File Systems

How to Consolidate Project-Related Files Under /ws

How to Set Up Different Architectures to Access a Shared Name Space

How to Support Incompatible Client Operating System Versions

How to Replicate Shared Files Across Several Servers

How to Apply Security Restrictions

How to Use a Public File Handle With Autofs

How to Use NFS URLs With Autofs

Disabling Autofs Browsability

How to Completely Disable Autofs Browsability on a Single NFS Client

How to Disable Autofs Browsability for All Clients

How to Disable Autofs Browsability on an NFS Client

Troubleshooting Autofs

Error Messages Generated by automount -v

Miscellaneous Error Messages

Other Errors With Autofs

Chapter 5 About Autofs

Autofs Programs

automount

automountd

Autofs Maps

Master Map

Example 5-1 Sample /etc/auto_master File

Mount Point /home

Mount Point /net

Mount Point /xfn

Direct Maps

Mount Point /-

Indirect Maps

How Autofs Works

Figure 5-1 /etc/init.d/autofs Script Starts automount

How Autofs Navigates Through the Network (Maps)

How Autofs Starts the Navigation Process (Master Map)

Figure 5-2 Navigation Through the Master Map

Autofs Mount Process

A Simple Autofs Mount

Hierarchical Mounting

Autofs Unmounting

How Autofs Selects the Nearest Read-Only Files for Clients (Multiple Locations)

Figure 5-3 Server Proximity

Autofs and Weighting

Variables in a Map Entry

Maps That Refer to Other Maps

Executable Autofs Maps

Modifying How Autofs Navigates the Network (Modifying Maps)

Default Autofs Behavior With Name Services

Figure 5-4 How Autofs Uses the Name Service

Autofs Reference

Metacharacters

Ampersand (&)

Asterisk (*)

Special Characters

How to Set Up a Common View of `/home`

How to Set Up `/home` With Multiple Home Directory File Systems

How to Consolidate Project-Related Files Under `/ws`

Error Messages Generated by `automount -v`

`automount`

`automountd`

Example 5-1 Sample `/etc/auto_master` File

Mount Point `/home`

Mount Point `/net`

Mount Point `/xfn`

Mount Point `/-`

Figure 5-1 `/etc/init.d/autofs` Script Starts `automount`

Ampersand (`&`)

Asterisk (`*`)