The following sections describe the syntax of automount maps, the auto_master default mount points, and the mount point required for direct maps.
In an indirect map, you can specify a simple name (no slashes) as the mount point for each indirect map—in other words, you specify a relative path name for each indirect map entry in the auto_master map. You can create as many other indirect maps as you like so that you can provide users access to files exported from one or more servers.
The syntax for indirect maps is shown below.
key [mount-options] server:pathname
The simple path name is key, which is used as the mount point for the resource. An optional, comma-separated list of options, [mount-options], controls the mounting of the resource. If no options are specified, the resource is mounted read-write. The name of the server and the path to the resource is server:pathname.
/usr/local auto_local
This auto_master entry points to the following auto_local indirect map.
# Indirect map for executables: auto_local # openwin -ro oak:/usr/openwin frame.6.0 ash:/usr/local/frame.6.0
You can include an integer in parentheses to specify more than one server location, use shortcuts and wildcard characters to shorten entries with similar characteristics, and set weighting factors for each server named. The most likely to be selected is (0); progressively higher values decrease the chance of being selected. For more information, see “Syntax and Shortcuts for Map Entries” .
The Solaris Operating Environment provides you with two default indirect automounter maps: auto_master and auto_home.
The master map is located in the /etc directory. As indicated earlier, this indirect map contains the default mount points /net and /home. Use the default mount points as a convenient way to maintain a consistent namespace.
The auto_master map has the following syntax.
mount-point map-name [mount-options]
The full path name of a directory is mount-point. If the directory does not exist, the automounter creates it if possible. The map used by the automounter to find the mount points and locations of the server's file systems is named map-name. Finally, mount-options is an optional list of comma-separated options that control the mounting of the entries specified by map-name. Options specified in the map-name map take precedence over options specified in the auto_master map. The mount-options used by the automounter are the same mount options used in the /etc/vfstab file. Table 33 shows the most common mount options. See the mount_nfs(1M) manual page for a complete list of NFS mount options.
The default auto_master map is shown below.
# Master map for automounter # +auto_master /net -hosts -nosuid,nobrowse /home auto_home -nobrowse /xfn -xfn
![]() | You can also have an /- entry for an auto_direct map, as shown below. |
# Master map for automounter # +auto_master /net -hosts -nosuid,nobrowse /home auto_home -nobrowse /xfn -xfn /- auto_direct -ro
See “The Direct Map” for more information about the direct map.
![]() | Starting with the Solaris 2.6 release, the automounter supports browsability of indirect maps. The browse feature enables all of the potential mount points to be visible, regardless of whether they are mounted. You can turn off the browse feature with the -nobrowse option. By default, the auto_master map specifies the -nobrowse option to the entries for /home and /net. See “Disabling Automounter Browsability” for more information. |
Each client system has a copy of the default /etc/auto_master map. The +auto_master entry provides a link to the NIS, NIS+, or LDAP auto_master map. This entry is the first entry in the file, to ensure that the nameservice auto_master map overrides information that is specified locally. The /xfn entry provides a way for the federated nameservice to map composite names to a reference. For more information on xfn, refer to the xfn(3N) manual page.
NOTE
The automounter provides backward compatibility with SunOS 4.x auto.master and other auto. files. If the automounter does not find any maps with an auto_ prefix, it searches for maps with the auto. prefix.
automount: files
The automounter uses the following entry in the nsswitch.conf file when the system is using the NIS nameservice.
automount: files nis
The automounter uses the following entry in the nsswitch.conf file when the system is using the NIS+ nameservice.
automount: files nisplus
The automounter uses the following entry in the nsswitch.conf file when the system is using the LDAP nameservice.
automount: files ldap
See “The Nameservice Switch” for more information.
The default auto_master map contains a /net mount point as part of an entry that automatically includes all of the systems under the special map -hosts. This built-in map uses the nameservice auto_master map to locate shared file systems on a remote host system when the user specifies a system by name. What this means to users is that they can gain access to any files on systems that are listed in the nameservice Hosts database with the usual Solaris commands. For example, suppose that Fred sends an e-mail telling you that a document is available on his system for review. Fred includes the system name—oak—and the path to the document— /export/home/fred/Newprojects/review.doc—in the e-mail message. He may show the path as /net/oak/export/home/fred/Newprojects/review.doc. To print the file without copying it to your local system, you would type the following command.
castle% lp /net/oak/export/home/fred/Newprojects/review.doc
castle%
To copy the file to your current working directory on your local system, you would type the following command.
castle% cp /net/oak/export/home/fred/Newprojects/review.doc .
castle%
If you know that the file is somewhere on the system named oak, but you are not sure of the complete path name, you can work your way down through the file system, as shown in the following example.
castle% cd /net/oak castle% ls export castle% cd export;ls home castle% cd home;ls fred ignatz newton magic castle% cd fred;ls Newprojects Status Oldprojects castle% cd Newprojects;ls review.doc castle% pwd /net/oak/export/home/fred/Newprojects castle%
NOTE
![]() | This example works only if the home directory is shared. |
The default auto_master map also contains a /home mount point and the auto_home map name so that you do not need to make a special entry in the auto_master map for auto_home. Sun recommends that you use /home/username as your naming convention instead of the /home/system-name/username convention.
![]() | The auto_master map is parsed from top to bottom. The top entry takes precedence. Consequently, when you use NIS+ maps to set up a global namespace, the local /etc/auto_master maps should always have the +auto_master entry at the top of the file unless you specifically want to override something in the auto_master NIS or NIS+ map or you want to create a local map for testing. |
You can add new entries to the nameservice auto_master map and take them away, although you should be careful when you delete entries from the nameservice auto_master map. For example, if you wanted to change the default mount point of the /net mount point, you could change the /net -hosts entry to /net -null and define your new mount point. For example, to change the mount point to /foo, you would add the following entry.
/net -null /foo -hosts -setuid
NOTE
Although you can change the default /net mount point, Sun recommends that you use the /net mount point to make the automounter easier to administer, to provide a consistent namespace for your users, and to ensure compatibility with future automounter releases.
When you create new indirect or direct maps, you must add the mount points and map names to the nameservice auto_master table so that the automounter knows to look for them. See Chapter 8, “Setting Up the Automounter,” for step-by-step instructions for creating indirect and direct maps and updating the auto_master map.
The home directory indirect map, located in the /etc directory, is named auto_home. The default map contains a +auto_home link to the nameservice auto_home database.
The auto_home map has the following syntax.
username [mount-options] server:pathname
The user's login name is username, which is used as the mount point for the home directory. An optional, comma-separated list of options, [mount-options], controls the mounting of the user's home directory. If no options are specified, the home directory is mounted read-write. The server:pathname variable specifies the name of the server and the path to the user's home directory.
The default auto_home map is shown below.
# Home directory map for automounter # +auto_home
The local path is displayed as /home/username.
In a direct map, you can specify an absolute path name as the mount point.
Direct maps have the following syntax.
key [mount-options] server:pathname
The absolute path name, key, is used as the mount point. An optional, comma-separated list of options, [mount-options], controls the mounting of the resource. If no options are specified, the resource is mounted read-write. The name of the server and the path to the resource are server:pathname.
You can have only one direct map—which, by convention, is named auto_direct—because you can have only one /- entry in the auto_master file. Use it for all of the file systems you want to mount with an absolute path name.
Manual pages are a good example of an entry you might want to automount in a direct map. /var/mail is another example, especially if you use a central mail hub where you keep all user mailboxes. To show you the difference between indirect and direct maps for manual pages, let's first see how an indirect map would look. If you created an indirect map named auto_man to automount manual pages from a server named oak on mount point /usr/man, you would put the following entry in the auto_master file so the automounter knows to look for the auto_man indirect map.
/usr/man auto_man -ro
This entry references the following auto_man indirect map.
# Indirect map for man pages: auto_man # man1 oak:/usr/share/man/man1 man1b oak:/usr/share/man/man1b man1c oak:/usr/share/man/man1c man1f oak:/usr/share/man/man1f man1m oak:/usr/share/man/man1m man1s oak:/usr/share/man/man1s man2 oak:/usr/share/man/man2 man3 oak:/usr/share/man/man3 man3b oak:/usr/share/man/man3b man3c oak:/usr/share/man/man3c man3e oak:/usr/share/man/man3e man3g oak:/usr/share/man/man3g man3i oak:/usr/share/man/man3i man3k oak:/usr/share/man/man3k man3m oak:/usr/share/man/man3m man3n oak:/usr/share/man/man3n man3r oak:/usr/share/man/man3r man3s oak:/usr/share/man/man3s man3x oak:/usr/share/man/man3x man4 oak:/usr/share/man/man4 man4b oak:/usr/share/man/man4b man5 oak:/usr/share/man/man5 man6 oak:/usr/share/man/man6 man7 oak:/usr/share/man/man7 man9 oak:/usr/share/man/man9 man9e oak:/usr/share/man/man9e man9f oak:/usr/share/man/man9f man9s oak:/usr/share/man/man9s manl oak:/usr/share/man/manl mann oak:/usr/share/man/mann
If you do not want to create directories for each manual group, you can instead create a direct map with a single entry to automount manual pages. You would add the following entry in the auto_master map.
/- auto_direct -ro
This entry references the following manual page auto_direct direct map.
# Direct map: auto_direct # # Entry for automounting manual pages # /usr/man oak:/usr/share/man
This map creates a direct association between the shared directory and the mount point. In this case, you can clearly see the benefits of using a direct map.
CAUTION
Be sparing in your use of a direct map. A direct map locks you into a direct path, which is difficult to change on the fly. By contrast, indirect maps are more flexible. You can move the top-level mount points easily by changing the entry in the auto_master map and running the automount command on each client to refresh their view of the automounter hierarchy.
The following sections describe the syntax and shortcuts you can use for map entries. The examples show indirect maps, but you can also use these same shortcuts for the mount-options and server:pathname fields of direct maps.
You can specify more than one server as the resource for one mount point. If you specify more than one server in the server:pathname field, the automounter mounts the file system from the first server that replies to the mount request from the local net or subnet. If no server responds, all of the servers on the list are retried.
The following syntax specifies multiple servers that contain identical copies of the same file system. The automounter could mount any of these file systems at the specified mount point on the client.
key [mount-options] server:pathname [mount-options] server:pathname [mount-options] server:pathname
The backslash at the end of each line tells the automounter to consider the entire entry as one line, and it makes the entry easier for administrators to read. The last entry line does not have a backslash because it ends the sequence. The following map entry example mounts the OpenWindows executable from one of the three listed servers.
openwin -ro oak:/usr/openwin -ro ash:/usr/openwin -ro elm:/usr/openwin
In the following entry, each server would be mounted with the same mount-options. You can combine the options after the key with the following syntax.
key [mount-options] server:pathname server:pathname server:pathname
The following example mounts any of these servers read-only.
openwin -ro oak:/usr/openwin ash:/usr/openwin elm:/usr/openwin
You can shorten the previous example because each of the locations uses the same path. Use the following syntax to combine the server names on one line and separate them with commas.
key [mount-options] server1,server2,server3:pathname
The following example combines mount-options for all servers and the names of the servers.
You can specify weighting factors for each server in the list by putting a number in parentheses after the name of the server. Server(0) is most likely to be selected, with progressively higher values decreasing the chance of being selected. If you do not specify a number, the automounter assumes all servers in the list have a (0) weighting, and thus they all have equal priority.
NOTE
Versions of the automounter earlier than the Solaris 2.1 release do not recognize the server-weighting values. When the automounter does not recognize the weighting values, servers with such values are ignored. Consequently, if you want to share automount maps among systems of various release levels, do not use the weighting factors.
The weighting factor syntax is shown below.
key [mount-options] server1(n),server2(n),server3(n):pathname
The following example combines mount-options for all servers and combines the names of the servers with weighting factors.
openwin -ro oak,ash(1),elm(2):/usr/openwin
In the above example, the server oak has the highest priority, (0), the server ash has the second highest priority, and the server elm, the third. The locations of the servers are shown in Figure 25.
You can use the weighting factor for any list of servers, whether they are on individual lines or are combined on the same line. Just place the weighting factor number in parentheses after the name of the server.
NOTE
Server proximity takes precedence over the weighting value. For example, a server on a local subnet is chosen even if it has a higher weighting value than a server on a different subnet. The weighting value is used to choose between servers that have the same network proximity.
The automounter provides predefined map variables, similar to environment variables, that you can use in defining paths. The Solaris map variables are ARCH and CPU.
When you include $ARCH as part of the path, the map variable returns the name of the system architecture as it would be returned by the uname -m command. In the following example, the uname -m command returns the architecture sun4u.
oak% uname -m sun4u oak%
When you include $CPU as part of the path, the map variable returns the name of the system architecture as it would be returned by the uname -p command. In the following example, the uname -p command returns the architecture sparc.
oak% uname -p sparc oak%
If you have a server exporting binaries for both SPARC and IA architectures from /usr/local/bin/sparc and /usr/local/bin/i486, respectively, you can use the $CPU command to create a map entry that mounts the binaries appropriate for each system's architecture. The entry would look like the following example.
bin -ro server:/usr/local/bin/$CPU
With this entry, the map can be used for clients running all architectures.
Starting with the Solaris 2.3 release, the additional predefined map variables shown in Table 34 are provided.
![]() | Metacharacters |
The automounter recognizes some special characters to use for substitutions or to protect other characters from the autofs map parser.
You can use the ampersand (&) as a string substitution character for the key. For example, consider the following example map that specifies many subdirectories.
winsor paperbark:/home/winsor ray paperbark:/home/ray des castle:/home/des rob seachild:/home/rob
You can use the ampersand character to substitute the key wherever it appears, as shown in the following example; this action changes the previous map.
winsor paperbark:/home/& ray paperbark:/home/& des castle:/home/& rob seachild:/home/&
You can also use key substitutions in a direct map. You can write the following example
/usr/man paperbark,castle,seachild:/usr/man
as
/usr/man paperbark,castle,seachild:&
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.
You can use the asterisk (*) to match any key. For example, you could use the following map entry to mount the /export file system from all hosts.
* &:/export
The value of any given key is substituted for each ampersand. Autofs interprets the asterisk as an end-of-file character.
The autofs parser is sensitive to names containing colons, commas, spaces, and so on. You should enclose these names in double quotes, as shown in the following example.
3.137.221.240