How Autofs Works

Autofs is a client-side service. 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.

Three 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 will be mounted in the future.

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

With this new implementation of automatic mounting the automountd daemon is completely independent from the automount command. Because of this separation, it's possible to add, delete, or change map information without first having to stop and start the automountd daemon process. Once the file system is mounted, further access does not require any action from automountd.

After initially mounting autofs mounts, the automount command is used to keep 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 daemons.

Unlike mount, automount does not read the /etc/vfstab file (which is specific to each computer) for a list of file systems to mount. The automount command is controlled within a domain and on computers through the namespace or local files.

This is a simplified overview of how autofs works:

The automount daemon automountd starts at boot time from the /etc/init.d/autofs script. This script also runs the automount command, which reads the master map (see "How Autofs Navigates Through the Network (Maps)" on page 69) and installs autofs mount points.

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:

1. Autofs intercepts the request.

2. Autofs sends a message to the automountd 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 five minutes 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 will not know that the object has been unmounted resulting in possible inconsistency. A reboot will clear all of the autofs mount points, if the service is confused by manual interaction.

---

Autofs Programs

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 which have many automounted file systems, it can be necessary 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 get very large. The output from df can be filtered by using the -F option (see the df(1B) man page) or by using egrep to help fix this problem.

Another factor to consider is that changing the duration also changes how quickly changes to the automounter maps will be reflected.

automountd

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

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

where -T selects to display each RPC call to standard output, -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 -T option is only recommended for troubleshooting.

Setting Up Autofs Maps

Autofs uses three types of maps:

• Master maps
• Direct maps
• Indirect maps

Master Maps

The auto_master map associates a directory with a map. It is a master list specifying all the maps that autofs should know about.

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

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.

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. The mount-options are the same as those for a standard NFS mount, except that bg (background) and fg (foreground) do not apply. See mount on page 15.

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

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

location

location is the location of the file system, specified (one or more) as server:pathname.

---

Warning - The pathname should not include an automounted mount point, it should be the actual absolute path to the files 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

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

There are important but previously unmentioned features in this map. See "How Autofs Selects the Nearest Read-Only Files for Clients (Multiple Locations)" on page 76 and "Multiple Mounts" on page 73.

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.

location

location is the location of the file system, specified (one or more) as server:pathname.

---

Warning - The pathname should not include an automounted mount point, it should be the actual absolute path to the files 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.

Table 5-1 showed an auto_master map that contained the entry:

/home auto_home

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 into 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 will 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.

---

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 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)" on page 81.

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.

For example, Table 5-1 shows what a typical auto_master file would contain:

Table 5-1 auto_master

Mount Point	Map	Mount options
/-	auto_direct	-ro
/home	auto_home	-nosuid
/net	-hosts	-nosuid

Autofs recognizes some special mount points and maps, which are explained in the following sections.

Mount Point /-

In Table 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. 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.)

A 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 they do not overlap.

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.

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. Note 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 may not be available through /net/gumbo.

---

Note - Autofs checks the server's export list only at mount time. Once a server's file systems are mounted, autofs does not check with the server again until the server's file systems are unmounted and then remounted. Therefore, newly exported file systems will not be seen until the file systems on the server are unmounted or remounted.

---

The Mount Process

When you issue the command in the previous example, autofs performs the following steps:

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

2. Requests the list of exported file systems from the server.

3. Sorts the exported list according to length of path name:

/usr/src /export/home /usr/src/sccs /export/root/client

This sorting ensures that the mounting is done in the required order (that is, /usr/src is done before /usr/src/sccs).

4. Proceeds down the list, mounting all the file systems at mount points.

Note that autofs has to mount all the file systems that the server in question exports. Even if the request is as follows.

% ls /net/gumbo/usr/include

Autofs mounts all of gumbo's exported systems, not just /usr.

If autofs is running on NFS servers, any maps that refer to file systems on the server should be checked for file name paths that pass through an autofs mount point. This causes an access through the loopback file system (LOFS) which cannot be exported. The entry would appear as follows.

brent creole:/home/brent

Replace it with this entry:

brent creole:/export/home/creole/brent

In previous releases, the mount daemon on the server would follow the automounter's symbolic link at /home/brent and find the exported file system. With autofs, the mount daemon finds a loopback mount at /home/brent that is not exportable so the client will not be able to mount it.

---

Note - Check existing maps to make sure that the server:/path portion of the map entry does not refer to an autofs mount point.

---

The unmounting that occurs after a certain amount of time is from the bottom up (reverse order of mounting). If one of the directories at the top is busy, autofs has to remount the unmounted file systems and try again later.

The -hosts special map provides a convenient way for users to access directories in many different hosts without having to use rlogin or rsh. They no longer have to modify /etc/vfstab files or mount the directories individually as superuser.

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 may no longer work. Also, because all exported file systems need to be mounted, using only one of those file systems is inefficient. Instead, you should set up an entry in a map specifically for the file system you want rather than use /net.

---

Note - Autofs runs on all computers and supports /net and /home (automounted home directories) by default. These defaults may 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.

---

Multiple Mounts

A map entry can describe multiple mounts. Multiple mounts enable users to access file systems from different locations. By having the same applications on several servers, users have an alternate source for that application if a particular server is down. Also, autofs can choose the quickest path for users (clients). Consider the first entry in "Direct Maps" on page 66:

/usr/local -ro \ /bin ivy:/export/local/sun3 \ /share ivy:/export/local/share\ /src ivy:/export/local/src

This is actually one long entry split into four lines using the backslash with the continuation lines indented with spaces or tabs. This entry mounts /usr/local/bin, /usr/local/share, and /usr/local/src from the server ivy, with the read-only option. The entry could also read:

/usr/local \ /bin -ro ivy:/export/local/sun3 \ /share -rw,secure willow:/usr/local/share\ /src -ro oak:/home/jones/src

where the options are different and more than one server is used. The previous example is equivalent to three separate entries, for example:

/usr/local/bin -ro ivy:/export/local/sun3 /usr/local/share -rw,secure willow:/usr/local/share /usr/local/src -ro oak:/home/jones/src

Multiple mounting guarantees that all three directories are mounted when you refer to one of them. If the entries are listed as separate mounts, then each of the directories is mounted only as needed. The first (multiple mount) case is accomplished with a single autofs mount at /usr/local. The second (single mounts) case results in three independent autofs mounts.

The mount root is a path relative to a direct autofs mount, or relative to the directory under an indirect autofs mount. This path describes where each file system should be mounted beneath an autofs mount point. This mount point theoretically should be specified by.

parsley / -ro veg:/usr/greens

But in practice, the mount point is not specified because in the case of a single mount as in the previous example, the location of the mount point is at the mount root or "/." So instead of the previous example, you would use this entry:

parsley -ro veg:/usr/greens

The mount-point specification is important in a multiple-mount entry. Autofs must have a mount point for each mount. When the entry specifies that one mount occur within another, the entry becomes a hierarchical mount, which is a special case of multiple mounts.

---

Note - A hierarchical mount can be a problem if the server for the root of the file system goes down. Because the unmounting has to proceed through the mount root, which also cannot be unmounted while its server is down, any attempt to unmount the lower branches fails.

---

The mount points used here for the file system are /, /bin, /share, and /src. Note that these mount point paths are relative to the mount root, not the host's file system root.

/usr/local \ / -rw peach:/export/local \ /bin -ro ivy:/export/local/sun3 \ /share -rw willow:/usr/local/share \ /src -ro oak:/home/jones/src

The first entry in the previous example has / as its mount point. It is mounted at the mount root. The first mount of a file system does not need to be at the mount root. Autofs issues mkdir commands to build a path to the first mount point if it is not at the mount root.

In these mount option examples:

/usr/local \ /bin -ro ivy:/export/local/$CPU \ /share -ro willow:/usr/local/share \ /src -ro oak:/home/jones/src

all three mounts share the same options. You can change this to:

/usr/local -ro\ /bin ivy:/export/local/sun4 \ /share willow:/usr/local/share \ /src oak:/home/jones/src

Administration is easier if there is only one set of mount options common to all mounts in the entry. If one of the mount points needs a different specification, you can write:

/usr/local -ro\ /bin ivy:/export/local/sun4 \ /share -rw,secure willow:/usr/local/share \ /src oak:/home/jones/src

You may want different mount options for some of the mounts; for example, to enable clients to update the files on one mount but not on the others.

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 users can mount from any of the replicated locations. This procedure makes sense only when you mount a file system that is read-only, since 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 will be mounted automatically without any effort required by the user.

A good example of this is man pages. In a large network, more than one server may 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

You could also enter this as a comma-separated list of servers, followed by a colon and the path name (as long as the path name is the same for all the replicated servers).

/usr/man -ro oak,rose(1),willow(2):/usr/man

Here you can mount the man pages from the servers oak, rose, or willow. 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 - Server proximity is more important than weighting. A server on the same network segment as the client is more likely to be selected than a server on another network segment, regardless of the weighting factors assigned.

---

This redundancy is used once at mount time to select one server from which to mount. Autofs does not check the status of the mounted-from server once the mount occurs, so this is not useful as a fail-over service. Multiple locations are very useful in an environment where individual servers may not be exporting 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.

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-2 shows the predefined map variables.

Table 5-2

Variable	Meaning	Derived From	Example
ARCH	Architecture type	uname -m	sun4c
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, you can have the clients mount through a map entry like the following:

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

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

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.

This name service switch file contains an entry for autofs, which contains the order in which the name services are searched. The file below 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

For example, 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/& bonny cs.csc.edu:/export/home/&

---

Note - If your /etc/auto_home or other local maps have the execute bit set, then autofs tries to execute it to obtain a map entry, instead of reading it. autofs logs errors to the console when the map is accessed.

---

To fix the problem, reset the execute bit:

# chmod -x /etc/auto_home

After consulting the included map, automount continues scanning the current map if no match is found. This means you can add more entries after a + entry.

bill cs.csc.edu:/export/home/& bonny cs.csc.edu:/export/home/& +auto_home * -nosuid &:/export/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

The wildcard means a match is found. Therefore, the wildcard should be the last entry in all cases, because autofs does not continue consulting the map after finding a wildcard.

---

Note - + entries cannot be used in NIS+ or NIS maps.

---

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.

Administrative Tasks Involving Maps

Listed below are the different administrative tasks you may need to perform involving maps in order to change your autofs environment.

• "How to Modify Indirect Maps" on page 83
• "How to Modify Direct Maps" on page 83
• "How to Modify the Master Map" on page 82
• "Avoiding Mount-Point Conflicts" on page 84

Table 5-3 describes the types of maps and their uses.

Table 5-3

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 5-4 describes how to make changes to your autofs environment based on your name service.

Table 5-4

Name Service	Method
Local files	text editor
NIS	make files
NIS+	nistbladm

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

Table 5-5 automount

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

Modifying the Maps

The following procedures assume that you are using NIS+ as your name service.

· How to Modify the Master Map

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

   See NIS+ and FNS Administration Guide.

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

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

4. 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 NIS+ and FNS 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

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

   See NIS+ and FNS Administration Guide.

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

3. 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 simply 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, and then access it. If this is not satisfactory, you

can unmount with the umount command and then access /usr/src. The mounting will now be done from the new server. If you deleted the entry, you would have to run the automount command for the deletion to take effect.

---

Note - Because of the additional steps, and because they do not take up as much room 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 autofs to mount other source directories, you may encounter a problem. If you specify the mount point /src, then autofs 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 the 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.

Default Autofs Behavior

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

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 that contains one or more underscores, the underscores are changed to dots. Then autofs looks up the map again, as shown in Figure 5-4.

The screen activity would look like the following example.

$ more /etc/auto_master # Master map for autofs # +auto_master /net -hosts -nosuid /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 map above 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 (*) The catchall substitute character, the asterisk (*), can be used to match any key. The /export file system from all hosts could be mounted 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 may 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"

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 examples below are given to show how this mounting could be done through autofs. The Volume Manager and autofs do not work together, so normally 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. For more information about Volume Manager, see System Administration Guide, Volume I.

· How to Access CD-ROM Applications

---

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 wish to mount must appear as a name following a colon.

· How to Access Diskettes Containing Data in PC-DOS Files

---

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 Start CacheFS

* Run the cfsadmin command to create a cache directory on the local disk.

# cfsadmin -c /var/cache

Add this line to the master map to cache home directories:

/home auto_home -fstype=cachefs,cachedir=/var/cache,backfstype=nfs

---

Note - Options that are included in maps that are searched later will override options that are set in maps that are searched earlier. The last options that are found are the ones that are used. In the example above, a specific entry added to the auto_home map would need to include the options listed in the master maps.

---

Common Tasks and Procedures

This section describes some of the most common tasks you may 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 NIS+ and FNS Administration Guide to perform the tasks discussed in this section.

---

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.

1. Create the auto_local map with the nistbladm command. See the NIS+ and FNS Administration Guide.

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

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

Note that the ro mount option implies that clients will not be able to write to any files or directories.

4. Export the appropriate directory on the server.

5. Include a bin entry in the map.

   Your directory structure looks like this:

bin aa:/export/local/bin

To satisfy the need to serve clients of different architectures, you need references to the bin directory to be directed to different directories on the server, depending on the clients' architecture type.

6. To serve clients of different architectures, change the entry by adding the autofs CPU variable.

bin aa:/export/local/bin/$CPU

---

Note - For SPARC 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

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

2. Create the following map entry.

bin aa:/export/local/bin/$CPU$OSREL

For SPARC clients running version 5.1 of the operating system, you need to export /export/local/bin/sparc5.1 from the server and similarly export for other releases. Since 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

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

bin aa,bb-68,bb-72,dd:/export/local/bin/$CPU

Several shared files may not have an architecture dependency. A good example of this is shell scripts. You can locate these shared files under /usr/local/share with an independent map entry like this:

share aa,bb-68,bb-72,dd:/export/local/share

To ensure that scripts refer to local executables, use architecture-independent paths either fully qualified or relative (for example, /usr/local/bin/frotz or ../bin/frotz).

Similarly, other applications may have their own wrapper scripts for handling client dependencies. You can also set up these scripts with their own map entries.

frame pp,qq:/export/local/frame/3.0 valid pp,rr,tt:/export/local/valid lotus pp,qq,zz:/export/local/lotus

The servers can use the same /usr/local map as the clients. Users who work on the server will see the same shared name space under /usr/local.

If the server's autofs notices that a directory under /usr/local is available on the server under /export/local, it will loopback mount the directory so that it appears under /usr/local. Servers must not mount local disks on or under /usr/local.

· How to Set Up a Common View of /home Directory Structure

You would like every user in the network 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 pre-installed master map: /etc/auto_master.

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

A map for auto_home is also preinstalled 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+.

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

· How to Apply Security Restrictions

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

/home auto_home -nosuid

This entry overrides the entry for /home in the 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.

---

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

---

· How to Set Up Home Directory Servers

1. Mount home directory partitions under /export/home. This directory is reserved for autofs.

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

2. 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/&

Note 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. This common view of all home directories is valuable when logging into another user's computer. Autofs there 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 into 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, only rusty's entry in the auto_home map needs to be changed to reflect the new location. Everyone else can continue to use the /home/rusty path.

· How to Consolidate Project-Related Files Under /ws

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.

1. Add an entry for the /ws directory to the site auto_master map, either NIS or NIS+.

/ws auto_ws -nosuid

The contents of the /ws directory are determined by the auto_ws map.

2. Add the -nosuid option as a precaution.

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

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 just 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. Each of these subdirectories must be assigned 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 bigger, 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 large amounts of disk space. Through the life of the project you may 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 since the directory hierarchy under /ws is not changed.

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

Troubleshooting Autofs

Occasionally, you may 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 autofs generates. The list is divided in two parts:

• Error messages generated by the verbose (-v) option of automount
• Error messages that may 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 may 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 what the problem may be.

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 may exist only in a file system that cannot be mounted (it may not 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 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 an NIS map. This may indicate NIS problems.

mount of server:pathname on mountpoint:reason

Autofs failed to do a mount. This may indicate a server or network problem.

mountpoint: Not a directory

  Autofs cannot mount itself on mountpoint because it's 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 may 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 will try to execute the maps, which will create 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