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

Three components that work together to accomplish automatic mounting are:

1. The automount command

2. The autofs file system

3. The automountd daemon

The automount command, called at system start-up 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 underneath them. For example, when autofs receives a request to access a file system that is not currently mounted, autofs calls the 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 having to stop and start the automountd daemon process first. Once the file system is mounted, further access does not require any action from the automountd.

After initially mounting autofs mounts, the automount command is used to keep autofs mounts as necessary by comparing the list of mounts in auto_master 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 autofs.

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

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 45) 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 5 minutes of inactivity.

Setting Up Autofs Maps

Autofs uses four types of maps:

• auto_home
• auto_master
• Direct maps
• Indirect maps

auto_home Map

The auto_home map associates user login names with their directory locations. It tells autofs to mount a home directory by pointing to the auto_home map. The map is a listing of all the users in the system, followed by the path to their home directory. To view the auto_home map, use Administration Tool. To bring up Administration Tool, type admintool at the command prompt.

auto_master Map

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

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.

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 the home directories. The auto_home map is an example of an indirect map.

autofs Command Syntax

To invoke autofs, use the following syntax.

/usr/sbin/automount [ -t mount-timeout ] [ -v ]

The automount(1M) man page contains a complete description of all options.

automountd Command Syntax

To invoke the automountd(1M) daemon, use the following syntax.

/usr/lib/autofs/automountd [ -Tv ] [ -D name=value ]

The automountd(1M) man page contains a complete description of all options.

Master Map Syntax

Each line in the master map /etc/auto_master has the following syntax.

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

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 and Indirect Map Syntax

Lines in direct and indirect maps have the following general syntax.

key [ mount-options] location

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

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.

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.

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 Administration Tool. See "Modifying How Autofs Navigates the Network (Modifying Maps)" on page 60.

There are four kinds of autofs maps:

• Auto_home--associates user login names with their directory locations
• Master--associates directories with maps
• Indirect--a directory containing automount points (used for most maps)
• Direct--an automount point (rarely used)

The following sections describe these maps.

How Autofs Starts the Navigation Process (Master Map)

Autofs 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 6-2. The specific order of the entries is not important. Autofs compares entries in the master map with entries in the mount table.

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

Table 6-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 6-1, the mount point /- tells autofs not to associate the entries in auto_direct with any directory. Indirect maps use mount points. Direct maps use mount points specified in the auto_direct map. (Remember, in a direct map the key, or mount point, is a full path name.)

A NIS or NIS+ auto_master can have only one direct map entry. An auto_master that is a local file can have any number of entries.

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 under /net/gumbo, for example, may not appear.

---

Note - Autofs checks the server's export list only at mount time. Once a server's filesystems 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/remounted.

---

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

1. pings the null procedure of 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/blah

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

---

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 map, or by local editing of the /etc/auto_master and /etc/auto_home file.

---

Direct Maps

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

A typical /etc/auto_direct map is:

/
 usr/local                 -ro\
    /bin                                      ivy:/export/local/sun3 \
    /share                                    ivy:/export/local/share\
    /src                                      ivy:/export/local/src
/usr/man                    -ro               oak,rose,willow:/usr/man
/usr/games                  -ro               peach:/usr/games
/usr/frame                  -ro               redwood:/usr/frame2.0 \
                                              balsa:/export/frame

There are a couple of important but previously unmentioned features in this map: multiple locations and multiple mounts, which are discussed in the next two sections.

How Autofs Finds Specific File Systems (Indirect Maps)

An indirect map is a directory containing automount points. Indirect maps are useful for accessing specific file systems, like the home directories. Figure 6-3 contrasts the indirect map structure with the direct map structure.

Table 6-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/&
rob                           cypress:/export/home/&
gordon                        poplar:/export/home/&
rajan                         pine:/export/home/&
tammy                         apple:/export/home/&
jim                           ivy:/export/home/&
linda       -rw,nosuid        peach:/export/home/&

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.

---

Note - Any option in the indirect map entry overrides all options in the master map.

---

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

On a network with NIS, you have to change all the relevant databases (such as /etc/passwd) on all systems on the network to accomplish this. Make the changes on the NIS master server and propagate the relevant databases to the slave servers. The auto_home map can be updated using Administration Tool. On a network running NIS+, propagating the relevant databases to the slave servers is done automatically.

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 /usr/frame -ro redwood:/usr/frame2.0 \ balsa:/export/frame

the mount points /usr/man and /usr/frame 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 less 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 by autofs once the mount occurs. Multiple locations are very useful in an environment where individual servers may not be exporting their file systems. If the server goes down while the mount is in effect, the file system becomes unavailable. You have the option to wait five minutes until the auto-unmount takes place and try again. (It takes autofs about 5 minutes to do an auto-unmount.) Next time autofs will choose one of the other, available servers. You can do the unmount yourself using the umount command (you must be superuser). For example:

# umount /shared/local/bin

This feature is particularly useful in a large network with many subnets. Autofs chooses the nearest server and therefore confine 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.

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 the previous example:

/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 blank 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 mount 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 the following.

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 type the following example.

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

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

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 brackets to delimit the name of the variable from appended letters or digits. Table 6-2 shows the predefined map variables.

Table 6-2

Variable	Meaning	Derived From	Example
ARCH	Architecture type	/usr/kvm/arch	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.1
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 map. The "+" means that the entry is referring to the master map. 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. This is an example of the 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 instance, 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/&

If a file's map has its execute bit set, then autofs tries to execute it to obtain a map entry, instead of reading it.

---

Note - If your /etc/auto_home or other local maps have the execute bit set, 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. For instance:

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 because NIS+ and NIS search the entry from right to left, not left to right.

---

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

Table 6-3 lists the different administrative tasks you may need to perform involving maps in order to change your autofs environment.

Table 6-3

Task
Creating maps Modifying indirect maps Modifying direct maps Modifying the auto_home map Modifying the master map Adding changes to a direct map Deleting changes from a direct map Creating an entry in the auto_master map

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

Table 6-4

Type of Map	Use
auto_home	Associates names with locations
auto_master	Associates a directory with a map
direct	Directs autofs to reference-oriented file systems
indirect	Directs autofs to specific file systems

Table 6-5 describes how to make changes to your autofs environment based on your name service.

Table 6-5

Name Service	Use
Local files	An editor
NIS	make files
NIS+	nistbladm

Table 6-6 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 make 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 6-6 automount

Type of Map	Run autofs?
	Add/Delete	Modify existing entry
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. For NIS or local file name services, see the appropriate documentation.

To modify the master map:

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

   See the Name Services 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 workstations.

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

To modify indirect maps:

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

See the Name Services Administration Guide.

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

To modify direct maps:

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

   See the Name Services 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 workstations.

---

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 instance, suppose you modify the map auto_direct so that the directory /usr/src 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.

Because of these extra 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 system 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, say on /export/src. You would then need, for example, an entry in /etc/vfstab that says:

/dsk/d0t3d0s5 - export/src ufs 1 yes -

and an entry in auto_src that says:

terra terra:/export/src

where terra is the name of the computer.

Default Autofs Behavior

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

Autofs uses the name service specified in the automount entry of the /etc/nsswitch.conf file. In the example below, the + indicates NIS+. If NIS+ is specified, as opposed to local or NIS, all map names are used as is. If NIS is selected (indicated by an absence of the + sign) 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 6-5.

The screen activity would look like the following example. Notice the + sign, indicating NIS+.

$ 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 previous map now looks like the following:

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

Asterisk (*)

Notice that all the previous entries have the same format. This enables you to use the catchall substitute character, the asterisk (*). The asterisk reduces the whole thing to:

* &:/export

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

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), that 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

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. You can also mount files on removable media using Volume Manager, but Volume Manager and autofs do not work together.

Instead of mounting a file system from a server, you put the media in the drive and reference it from the map. Examples of CD-ROM applications are packages such as unbundled products and features. An example of a floppy drive application is DOS. 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 File System Administration.

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.

To access floppy disks containing data in PC-DOS files:

---

Note - Use this procedure if you are not using Volume Manager.

---

* Specify the floppy 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.

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

cfsadmin -c /usr/cache

The following example shows in bold the string you would add to the master map to cache home directories.

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

Common Problems and Recommended Solutions

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

---

Note - Use Administration Tool or see the Name Services Administration Guide to perform the tasks discussed in this section. If you are using local files, or NIS, see the appropriate documentation.

---

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

Problem:

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.

Solution:

1. Create the auto_local map using the nistbladm command. See the Name Services 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/scrag 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 the following:

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

---

SPARC - For SPARC clients, make executables available under /export/local/bin/sparc/ on the server. For x86 clients, use /export/local/bin/x86.

---

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.

To replicate shared files across several servers:

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

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 the following:

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 the /home Directory Structure

Problem:

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, client or server.

Solution:

Every Solaris computer 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 map, either NIS or NIS+.

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

To apply security restrictions:

* Create the following entry in the name service auto_master map, 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.

---

To set up the 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 Database Manager of the Administration Tool on-line facility 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/ws Directory Structure)

Problem:

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

Solution:

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 set uid 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 the following:

compiler alpha:/export/ws/compiler

This first attempt provides a map that looks quite simple, but perhaps too simple. It turns out that it is not adequate. 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 bravo:/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 easily 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 via loopback mounts in lieu of NFS mounts.

Troubleshooting Autofs

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

This section is written especially for advanced system administrators and programmers, and you can skip it without your ability to administer autofs being affected. However, you may want to read it to have an idea of the issues involved.

The second section presents a list of the error messages autofs generates. The list is divided in two parts:

1. Error messages generated by the verbose (-v) option of automount

2. Error messages that may appear at any time

Start autofs with the verbose option, otherwise you may experience problems without knowing why.

Reference for Autofs Troubleshooting

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 the Verbose Option

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.

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 the previous example, the warning is generated when autofs encounters the second line because the first line should be terminated with a backslash (\).

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.

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.

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.

WARNING: mount point already mounted on

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

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.

remount server:pathname on mount point: server not
responding

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

General Error Messages

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.

host server not responding

Autofs attempted to contact but received no response.

Mount of server:pathname on mount point: reason

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

pathconf: server: server not responding

Autofs is unable to contact the mount daemon on server that provides (POSIX)
pathconf() information.

pathconf: no info for server:pathname

Autofs failed to get path conf information for pathname.

hierarchical mountpoints: pathname1 and pathname2

Autofs does not allow its mount points to have a hierarchical relationship. An autofs mountpoint must not be contained within another automounted file system.

mountpoint: Not a directory

Autofs cannot mount itself on mount point because it's not a directory.  Check
the spelling and path name of the mount point.

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.

mapname: nis_err

Error in looking up an entry in an NIS map.  This may indicate NIS problems.

hostname: exports: rpc_err

Error getting export list from hostname. This indicates a server or network problem.

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.