This chapter provides information on how to perform autofs administration tasks, such as modifying automounter maps, using the automounter to reach non-NFS type devices, and how to configure maps.
This section includes procedures to start and stop the autofs service.
To enable the daemon without rebooting, become superuser and type the following command.
# /etc/init.d/autofs start |
This starts the daemon.
To disable the daemon without rebooting, become superuser and type the following command.
# /etc/init.d/autofs stop |
This section describes some of the most common tasks you might encounter in your own environment. Recommended procedures are included for each scenario to help you configure autofs to best meet your clients' needs.
Use the Solstice System Management Tools or see the Solaris Naming Administration Guide to perform the tasks discussed in this section.
The following list shows the different administrative tasks you might need to perform involving maps to change your autofs environment.
"Avoiding Mount-Point Conflicts "
Table 4-1 describes the types of maps and their uses.
Type of Map |
Use |
---|---|
Associates a directory with a map |
|
Directs autofs to specific file systems |
|
Directs autofs to reference-oriented file systems |
Table 4-2 describes how to make changes to your autofs environment based on your name service.
Table 4-2 Map Maintenance
Name Service |
Method |
---|---|
Local files |
Text editor |
NIS |
make files |
NIS+ |
nistbladm |
Table 4-3 tells you when to run the automount command depending on the modification you have made to the type of map. For example, if you've made an addition or a deletion to a direct map, you need to run the automount command on the local system to allow the change take effect; however, if you've modified an existing entry, you do not need to run the automount command to make the change take effect.
Table 4-3 When to Run the automount Command
Type of Map |
Restart automount? |
|
---|---|---|
|
Addition or Deletion |
Modification |
Y |
Y |
|
Y |
N |
|
N |
N |
The following procedures require that you are using NIS+ as your name service.
Using the nistbladm command, make the changes you want to the master map.
See the Solaris Naming Administration Guide.
For each client, become superuser by typing su at a prompt and then the superuser password.
For each client, run the automount command to ensure the changes you made take effect.
Notify your users of the changes.
Notification is required so that the users can also run the automount command as superuser on their own computers.
The automount command consults the master map whenever it is run.
Using the nistbladm command, make the changes you want to the indirect map.
See the Solaris Naming Administration Guide.
The change takes effect the next time the map is used, which is the next time a mount is done.
Using the nistbladm command, add or delete the changes you want to the direct map.
See the Solaris Naming Administration Guide.
If you added or deleted a mount-point entry in step 1, run the automount command.
Notify your users of the changes.
Notification is required so that the users can also run the automount command as superuser on their own computers.
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.
Because of the additional steps, and because they do not take up as much space in the mount table as direct maps, use indirect maps whenever possible. They are easier to construct, and less demanding on the computers' file systems.
If you have a local disk partition mounted on /src and you also want to use the autofs service to mount other source directories, you can encounter a problem. If you specify the mount point /src, the service hides the local partition whenever you try to reach it.
You need to mount the partition somewhere else; for example, on /export/src. You would 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.
Autofs can also mount files other than NFS files. Autofs mounts files on removable media, such as diskettes or CD-ROM. Normally, you would mount files on removable media using the Volume Manager. The following examples show how this mounting could be done through autofs. The Volume Manager and autofs do not work together, so these entries would not be used without first deactivating the Volume Manager.
Instead of mounting a file system from a server, you put the media in the drive and reference it from the map. If you want to access non-NFS file systems and you are using autofs, see the following procedures. For more information about Volume Manager, see the System Administration Guide.
Use this procedure if you are not using Volume Manager.
Specify the CD-ROM file system type as follows:
hsfs -fstype=hsfs,ro :/dev/sr0 |
The CD-ROM device you want to mount must appear as a name following a colon.
Use this procedure if you are not using Volume Manager.
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.
Run the cfsadmin command to create a cache directory on the local disk.
# cfsadmin -c /var/cache |
Add the cachefs entry to the appropriate automounter map.
For example, adding this entry to the master map will cache all home directories:
/home auto_home -fstype=cachefs,cachedir=/var/cache,backfstype=nfs |
Adding this entry to the auto_home map will only cache the home directory for the user named rich:
rich -fstype=cachefs,cachedir=/var/cache,backfstype=nfs dragon:/export/home1/rich |
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 previous example, a specific entry added to the auto_home map would only need to include the options listed in the master maps if some of the options needed to be changed.
There are several ways to set up the automounter maps. The following tasks give detailed instructions on how to customize the automounter maps to provide an easy-to-use directory structure.
The ideal is for every network user to be able to locate their own, or anyone else's home directory under /home. This view should be common across all computers, whether client or server.
Every Solaris installation comes with a master map: /etc/auto_master.
# Master map for autofs # +auto_master /net -hosts -nosuid,nobrowse /home auto_home -nobrowse /xfn -xfn |
A map for auto_home is also installed under /etc.
# Home directory map for autofs # +auto_home |
Except for a reference to an external auto_home map, this map is empty. If the directories under /home are to be common to all computers, then do not modify this /etc/auto_home map. All home directory entries should appear in the name service files, either NIS or NIS+.
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.
Install home directory partitions under /export/home.
If there are several partitions, install them under separate directories, for example, /export/home1, /export/home2, and so on.
Use the Solstice System Management Tools to create and maintain the auto_home map.
Whenever you create a new user account, type the location of the user's home directory in the auto_home map. Map entries can be simple, for example:
rusty dragon:/export/home1/& gwenda dragon:/export/home1/& charles sundog:/export/home2/& rich dragon:/export/home3/& |
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 and the key in the map. This common view of all home directories is valuable when logging in to another user's computer. Autofs mounts your home directory for you. Similarly, if you run a remote windowing system client on another computer, the client program has the same view of the /home directory as you do on the computer providing the windowing system display.
This common view also extends to the server. Using the previous example, if rusty logs in to the server dragon, autofs there provides direct access to the local disk by loopback-mounting /export/home1/rusty onto /home/rusty.
Users do not need to be aware of the real location of their home directories. If rusty needs more disk space and needs to have his home directory relocated to another server, you need only change rusty's entry in the auto_home map to reflect the new location. Everyone else can continue to use the /home/rusty path.
You are the administrator of a large software development project. You want to make all project-related files available under a directory called /ws. This directory is to be common across all workstations at the site.
Add an entry for the /ws directory to the site auto_master map, either NIS or NIS+.
/ws auto_ws -nosuid |
The auto_ws map determines the contents of the /ws directory.
Add the -nosuid option as a precaution.
This option prevents users from running setuid programs that might exist in any workspaces.
Add entries to the auto_ws map.
The auto_ws map is organized so that each entry describes a subproject. Your first attempt yields a map that looks like the following:
compiler alpha:/export/ws/& windows alpha:/export/ws/& files bravo:/export/ws/& drivers alpha:/export/ws/& man bravo:/export/ws/& tools delta:/export/ws/& |
The ampersand (&) at the end of each entry is 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. You must assign each of these subdirectories to an entire disk partition on the server.
Modify the entries in the map as follows:
compiler \ /vers1.0 alpha:/export/ws/&/vers1.0 \ /vers2.0 bravo:/export/ws/&/vers2.0 \ /man bravo:/export/ws/&/man windows \ /vers1.0 alpha:/export/ws/&/vers1.0 \ /man bravo:/export/ws/&/man files \ /vers1.0 alpha:/export/ws/&/vers1.0 \ /vers2.0 bravo:/export/ws/&/vers2.0 \ /vers3.0 bravo:/export/ws/&/vers3.0 \ /man bravo:/export/ws/&/man drivers \ /vers1.0 alpha:/export/ws/&/vers1.0 \ /man bravo:/export/ws/&/man tools \ / delta:/export/ws/& |
Although the map now appears to be much 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 substantial amounts of disk space. Through the life of the project you might be required to relocate and expand various disk partitions. As long as these changes are reflected in the auto_ws map, the users do not need to be notified, as the directory hierarchy under /ws is not changed.
Because the servers alpha and bravo view the same autofs map, any users who log in to these computers 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.
You need to assemble a shared name space for local executables, and applications, such as spreadsheet tools and word-processing packages. The clients of this name space use several different workstation architectures that require different executable formats. Also, some workstations are running different releases of the operating system.
Create the auto_local map with the nistbladm command.
See the Solaris Naming Administration Guide.
Choose a single, site-specific name for the shared name space so that files and directories that belong to this space are easily identifiable.
For example, if you choose /usr/local as the name, then the path /usr/local/bin is obviously a part of this name space.
For ease of user community recognition, create an autofs indirect map and mount it at /usr/local. Set up the following entry in the NIS+ (or NIS) auto_master map:
/usr/local auto_local -ro |
Note that the ro mount option implies that clients will not be able to write to any files or directories.
Export the appropriate directory on the server.
Include a bin entry in the auto_local map.
Your directory structure looks like this:
bin aa:/export/local/bin |
To satisfy the need to serve clients of different architectures, you need references to the bin directory to be directed to different directories on the server, depending on the clients' architecture type.
To serve clients of different architectures, change the entry by adding the autofs CPU variable.
bin aa:/export/local/bin/$CPU |
For SPARCstationTM clients, make executables available under /export/local/bin/sparc on the server. For x86 clients, use /export/local/bin/i386.
Combine the architecture type with a variable that determines the operating system type of the client.
The autofs OSREL variable can be combined with the CPU variable to form a name that determines both CPU type and OS release.
Create the following map entry.
bin aa:/export/local/bin/$CPU$OSREL |
For SPARC clients running version 5.1 of the operating system, you need to export /export/local/bin/sparc5.1 from the server and similarly export for other releases. Because operating systems attempt to preserve backward compatibility with executable formats, assume that the OS release is not a factor and eliminate it from future examples.
So far, you have set up an entry for a single server aa. In a large network, you want to replicate these shared files across several servers. Each server should have a close network proximity to the clients it serves so that NFS traffic is confined to local network segments.
The best way to share replicated file systems that are read-only is to use failover. See "Client-Side Failover" for a discussion of failover.
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.
/home auto_home -nosuid |
The nosuid option prevents users from creating files with the setuid or setgid bit set.
This entry overrides the entry for /home in a generic local /etc/auto_master file (see the previous example) because the +auto_master reference to the external name service map occurs before the /home entry in the file. If the entries in the auto_home map include any mount options, then the nosuid option would be overwritten, so either no options should be used in the auto_home map or the nosuid option must be included with each entry.
Do not mount the home directory disk partitions on or under /home on the server.
The default version of /etc/auto_master that is installed with the Solaris 2.6 release has the -nobrowse option added to the entries for /home and /net. In addition, the upgrade procedure adds the -nobrowse option to the /home and /net entries in /etc/auto_master if these entries have not been modified. However, it might be necessary to make these changes manually or to turn off browsability for site-specific autofs mount points after the installation.
You can turn off the browsability feature in two ways. Disable it using a command-line option to the automountd daemon, which completely disables autofs browsability for the client. Or disable it for each map entry on all clients using the autofs maps in either a NIS or NIS+ name space, or for each map entry on each client using local autofs maps if no network-wide name space is being used.
Add the -n option to the startup script.
As root, edit the /etc/init.d/autofs script and add the -n option to the line that starts the automountd daemon:
/usr/lib/autofs/automountd -n \ < /dev/null > /dev/console 2>&1 # start daemon |
Restart the autofs service.
# /etc/init.d/autofs stop # /usr/init.d/autofs start |
To disable browsability for all clients, you must employ a name service such as NIS or NIS+. Otherwise, you need to manually edit the automounter maps on each client. In this example, the browsability of the /home directory is disabled. You must follow this procedure for each indirect autofs node that needs to be disabled.
Add the -nobrowse option to the /home entry in the name service auto_master file.
/home auto_home -nobrowse |
On all clients: run the automount command.
The new behavior takes effect after running the automount command on the client systems or after a reboot.
# /usr/sbin/automount |
In this example, browsability of the /net directory is disabled. The same procedure can be used for /home or any other autofs mount points.
Check the automount entry in /etc/nsswitch.conf.
For local file entries to take precedence, the entry in the name service switch file should list files before the name service. For example:
automount: files nisplus |
This is the default configuration in a standard Solaris installation.
Check the position of the +auto_master entry in /etc/auto_master.
For additions to the local files to take precedence over the entries in the name space, the +auto_master entry must be moved below /net:
# Master map for automounter # /net -hosts -nosuid /home auto_home /xfn -xfn +auto_master |
A standard configuration places the +auto_master entry at the top of the file. This prevents any local changes from being used.
Add the -nobrowse option to the /net entry in the /etc/auto_master file.
/net -hosts -nosuid,nobrowse |
On all clients: run the automount command.
The new behavior takes effect after running the automount command on the client systems or after a reboot.
# /usr/sbin/automount |
Occasionally, you might encounter problems with autofs. This section should make the problem-solving process easier. It is divided into two subsections.
This section presents a list of the error messages autofs generates. The list is divided in two parts:
Error messages generated by the verbose (-v) option of automount
Error messages that might appear at any time
Each error message is followed by a description and probable cause of the message.
When troubleshooting, start the autofs programs with the verbose (-v) option, otherwise, you might experience problems without knowing why.
The following paragraphs are labeled with the error message you are likely to see if autofs fails, and a description of the possible problem.
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.
The mount daemon on the server refuses to provide a file handle for server:pathname. Check the export table on server.
Autofs was unable to create a mount point required for a mount. This most frequently occurs when attempting to hierarchically mount all of a server's exported file systems. A required mount point can exist only in a file system that cannot be mounted (it cannot be exported) and it cannot be created because the exported parent file system is exported read-only.
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 (\).
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.
Autofs is attempting to mount over an existing mount point. This means there is an internal error in autofs (an anomaly).
Automounter mount point must be given as full path name. Check the spelling and path name of the mount point.
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.
Autofs attempted to contact but received no response.
Error getting export list from hostname. This indicates a server or network problem.
The map entry is malformed, and autofs cannot interpret it. Recheck the entry; perhaps there are characters in it that need escaping.
Error in looking up an entry in a NIS map. This can indicate NIS problems.
Autofs failed to do a mount. This can indicate a server or network problem.
Autofs cannot mount itself on mountpoint because it's not a directory. Check the spelling and path name of the mount point.
Autofs cannot send a query packet to a server in a list of replicated file system locations.
Autofs cannot receive replies from any of the servers in a list of replicated file system locations.
All these error messages indicate problems attempting to ping servers for a replicated file system. This can indicate a network problem.
Autofs failed to get pathconf information for pathname (see the fpathconf(2) man page).
Autofs is unable to contact the mount daemon on server that provides the information to pathconf().
If the /etc/auto* files have the execute bit set, then the automounter will try to execute the maps, which creates messages like:
/etc/auto_home: +auto_home: not found
In this case, the auto_home file has incorrect permissions. Each entry in the file will generate an error message much like this one. The permissions to the file should be reset by typing the following command:
# chmod 644 /etc/auto_home |