Part III Accessing Network File Systems Topics

Chapter 13, Managing Network File Systems (Overview)

Provides overview information for the NFS service

Chapter 14, Network File System Administration (Tasks)

Provides step-by-step instructions for setting up and troubleshooting the NFS service

Chapter 15, Accessing Network File Systems (Reference)

Provides background information on the NFS service

Chapter 13 Managing Network File Systems (Overview)

This chapter provides an overview of the NFS service, which can be used to access file systems over the network. The chapter includes a discussion of the concepts necessary to understand the NFS service and a description of the latest features in NFS and autofs.

• NFS Terminology

• About the NFS Service

• About Autofs

• Features of the NFS Service

NFS Terminology

This section presents some of the basic terminology that must be understood to work with the NFS service. Expanded coverage of the NFS service is included in Chapter 15, Accessing Network File Systems (Reference).

NFS Servers and Clients

The terms client and server are used to describe the roles that a computer assumes when sharing file systems. Computers that share their file systems over a network are acting as servers. The computers that are accessing the file systems are said to be clients. The NFS service enables any computer to access any other computer's file systems. At the same time, the NFS service provides access to its own file systems. A computer can assume the role of client, server, or both client and server at any particular time on a network.

Clients access files on the server by mounting the server's shared file systems. When a client mounts a remote file system, the client does not make a copy of the file system. Rather, the mounting process uses a series of remote procedure calls that enable the client to access the file system transparently on the server's disk. The mount resembles a local mount. Users type commands as if the file systems were local. See Mounting File Systems for information about tasks that mount file systems.

After a file system has been shared on a server through an NFS operation, the file system can be accessed from a client. You can mount an NFS file system automatically with autofs. See Automatic File-System Sharing and Task Overview for Autofs Administration for tasks that involve the share command and autofs.

NFS File Systems

The objects that can be shared with the NFS service include any whole or partial directory tree or a file hierarchy—including a single file. A computer cannot share a file hierarchy that overlaps a file hierarchy that is already shared. Peripheral devices such as modems and printers cannot be shared.

In most UNIX system environments, a file hierarchy that can be shared corresponds to a file system or to a portion of a file system. However, NFS support works across operating systems, and the concept of a file system might be meaningless in other, non-UNIX environments. Therefore, the term file system refers to a file or file hierarchy that can be shared and be mounted with NFS.

About the NFS Service

The NFS service enables computers of different architectures that run different operating systems to share file systems across a network. NFS support has been implemented on many platforms that range from the MS-DOS to the VMS operating systems.

The NFS environment can be implemented on different operating systems because NFS defines an abstract model of a file system, rather than an architectural specification. Each operating system applies the NFS model to its file system semantics. This model means that file system operations such as reading and writing function as though the operations are accessing a local file.

The NFS service has the following benefits:

• Enables multiple computers to use the same files, so everyone on the network can access the same data

• Reduces storage costs by having computers share applications instead of needing local disk space for each user application

• Provides data consistency and reliability because all users can read the same set of files

• Makes mounting of file systems transparent to users

• Makes accessing of remote files transparent to users

• Supports heterogeneous environments

• Reduces system administration overhead

The NFS service makes the physical location of the file system irrelevant to the user. You can use the NFS implementation to enable users to see all the relevant files regardless of location. Instead of placing copies of commonly used files on every system, the NFS service enables you to place one copy on one computer's disk. All other systems access the files across the network. Under NFS operation, remote file systems are almost indistinguishable from local file systems.

About Autofs

File systems that are shared through the NFS service can be mounted by using automatic mounting. Autofs, a client-side service, is a file system structure that provides automatic mounting. The autofs file system is initialized by automount, which is run automatically when a system is booted. The automount daemon, automountd, runs continuously, mounting and unmounting remote directories as necessary.

Whenever a client computer that is running automountd tries to access a remote file or remote directory, the daemon mounts the remote file system. This remote file system remains mounted for as long as needed. If the remote file system is not accessed for a certain period of time, the file system is automatically unmounted.

Mounting need not be done at boot time, and the user no longer has to know the superuser password to mount a directory. Users do not need to use the mount and umount commands. The autofs service mounts and unmounts file systems as required without any intervention by the user.

Mounting some file hierarchies with automountd does not exclude the possibility of mounting other hierarchies with mount. A diskless computer must mount / (root), /usr, and /usr/kvm through the mount command and the /etc/vfstab file.

Task Overview for Autofs Administration and How Autofs Works give more specific information about the autofs service.

Features of the NFS Service

This section describes the important features that are included in the NFS service.

NFS Version 2 Protocol

Version 2 was the first version of the NFS protocol in wide use. Version 2 continues to be available on a large variety of platforms. All Solaris releases support version 2 of the NFS protocol, but Solaris releases prior to Solaris 2.5 support version 2 only.

NFS Version 3 Protocol

An implementation of NFS version 3 protocol was a new feature of the Solaris 2.5 release. Several changes have been made to improve interoperability and performance. For optimal use, the version 3 protocol must be running on both the NFS servers and clients.

This version enables safe asynchronous writes on the server, which improve performance by allowing the server to cache client write requests in memory. The client does not need to wait for the server to commit the changes to disk, so the response time is faster. Also, the server can batch the requests, which improves the response time on the server.

Many Solaris NFS version 3 operations return the file attributes, which are stored in the local cache. Because the cache is updated more often, the need to do a separate operation to update this data arises less often. Therefore, the number of RPC calls to the server is reduced, improving performance.

The process for verifying file access permissions has been improved. Version 2 generated a “write error” message or a “read error” message if users tried to copy a remote file without the appropriate permissions. In version 3, the permissions are checked before the file is opened, so the error is reported as an “open error.”

The NFS version 3 protocol removed the 8-Kbyte transfer size limit. Clients and servers could negotiate whatever transfer size the clients and servers support, rather than conform to the 8-Kbyte limit imposed in version 2. Note that in the Solaris 2.5 implementation the protocol defaulted to a 32-Kbyte transfer size.

NFS ACL Support

Access control list (ACL) support was added in the Solaris 2.5 release. ACLs provide a finer-grained mechanism to set file access permissions than is available through standard UNIX file permissions. NFS ACL support provides a method of changing and viewing ACL entries from a Solaris NFS client to a Solaris NFS server. See “Using Access Control Lists (ACLs)” in System Administration Guide: Security Services for more information about ACLs.

NFS Over TCP

The default transport protocol for the NFS protocol was changed to the Transport Control Protocol (TCP) in the Solaris 2.5 release. TCP helps performance on slow networks and wide area networks. TCP also provides congestion control and error recovery. NFS over TCP works with version 2 and version 3. Prior to 2.5, the default NFS protocol was User Datagram Protocol (UDP).

Network Lock Manager and NFS

The Solaris 2.5 release also included an improved version of the network lock manager. The network lock manager provided UNIX record locking and PC file sharing for NFS files. The locking mechanism is now more reliable for NFS files, so commands that use locking are less likely to hang.

NFS Large File Support

The Solaris 2.6 implementation of the NFS version 3 protocol was changed to correctly manipulate files that were larger than 2 Gbytes. The NFS version 2 protocol and the Solaris 2.5 implementation of the version 3 protocol could not handle files that were larger than 2 Gbytes.

NFS Client Failover

Dynamic failover of read-only file systems was added in the Solaris 2.6 release. Failover provides a high level of availability for read-only resources that are already replicated, such as man pages, other documentation, and shared binaries. Failover can occur anytime after the file system is mounted. Manual mounts can now list multiple replicas, much like the automounter in previous releases. The automounter has not changed, except that failover need not wait until the file system is remounted. See How to Use Client-Side Failover and Client-Side Failover for more information.

Kerberos Support for the NFS Service

Support for Kerberos V4 clients was included in the Solaris 2.0 release. In the 2.6 release, the mount and share commands were altered to support NFS version 3 mounts that use Kerberos V5 authentication. Also, the share command was changed to enable multiple authentication flavors for different clients. See RPCSEC_GSS Security Flavor for more information about changes that involve security flavors. See “Configuring SEAM NFS Servers” in System Administration Guide: Security Services for information about Kerberos V5 authentication.

WebNFS Support

The Solaris 2.6 release also included the ability to make a file system on the Internet accessible through firewalls. This capability was provided by using an extension to the NFS protocol. One of the advantages to using the WebNFS^TM protocol for Internet access is its reliability. The service is built as an extension of the NFS version 3 and version 2 protocol. In addition, the WebNFS implementation provides the ability to share these files without the administrative overhead of an anonymous ftp site. See Security Negotiation for the WebNFS Service for a description of more changes that are related to the WebNFS service. See WebNFS Administration Tasks for more task information.

RPCSEC_GSS Security Flavor

A security flavor, called RPCSEC_GSS, is supported in the Solaris 7 release. This flavor uses the standard GSS-API interfaces to provide authentication, integrity, and privacy, as well as enabling support of multiple security mechanisms. See Kerberos Support for the NFS Service for more information about support of Kerberos V5 authentication. See GSS-API Programming Guide for more information about GSS-API.

Solaris 7 Extensions for NFS Mounting

The Solaris 7 release includes extensions to the mount command and automountd command. The extensions enable the mount request to use the public file handle instead of the MOUNT protocol. The MOUNT protocol is the same access method that the WebNFS service uses. By circumventing the MOUNT protocol, the mount can occur through a firewall. Additionally, because fewer transactions need to occur between the server and the client, the mount should occur faster.

The extensions also enable NFS URLs to be used instead of the standard path name. Also, you can use the public option with the mount command and the automounter maps to force the use of the public file handle. See WebNFS Support for more information about changes to the WebNFS service.

Security Negotiation for the WebNFS Service

A new protocol has been added to enable a WebNFS client to negotiate a security mechanism with an NFS server in the Solaris 8 release. This protocol provides the ability to use secure transactions when using the WebNFS service. See How WebNFS Security Negotiation Works for more information.

NFS Server Logging

In the Solaris 8 release, NFS server logging enables an NFS server to provide a record of file operations that have been performed on its file systems. The record includes information on what file was accessed, when the file was accessed, and who accessed the file. You can specify the location of the logs that contain this information through a set of configuration options. You can also use these options to select the operations that should be logged. This feature is particularly useful for sites that make anonymous FTP archives available to NFS and WebNFS clients. See How to Enable NFS Server Logging for more information.

Autofs Features

Autofs works with file systems that are specified in the local namespace. This information can be maintained in NIS, NIS+, or local files.

A fully multithreaded version of automountd was included in the Solaris 2.6 release. This enhancement makes autofs more reliable and enables concurrent servicing of multiple mounts, which prevents the service from hanging if a server is unavailable.

The new automountd also provides better on-demand mounting. Previous releases would mount an entire set of file systems if the file systems were hierarchically related. Now, only the top file system is mounted. Other file systems that are related to this mount point are mounted when needed.

The autofs service supports browsability of indirect maps. This support enables a user to see what directories could be mounted, without having to actually mount each one of the file systems. A -nobrowse option has been added to the autofs maps so that large file systems, such as /net and /home, are not automatically browsable. Also, you can turn off autofs browsability on each client by using the -n option with automount. See Disabling Autofs Browsability for more information.

Chapter 14 Network File System Administration (Tasks)

This chapter provides information on how to perform such NFS administration tasks as setting up NFS services, adding new file systems to share, and mounting file systems. The chapter also covers the use of the Secure NFS system, and the use of WebNFS functionality. The last part of the chapter includes troubleshooting procedures and a list of some of the NFS error messages and their meanings.

• Automatic File-System Sharing

• Mounting File Systems

• Setting Up NFS Services

• Administering the Secure NFS System

• WebNFS Administration Tasks

• Task Overview for Autofs Administration

• Strategies for NFS Troubleshooting

• NFS Troubleshooting Procedures

• NFS Error Messages

Your responsibilities as an NFS administrator depend on your site's requirements and the role of your computer on the network. You might be responsible for all the computers on your local network, in which instance you might be responsible for determining these configuration items:

• Which computers should be dedicated servers

• Which computers should act as both servers and clients

• Which computers should be clients only

Maintaining a server after it has been set up involves the following tasks:

• Sharing and unsharing file systems as necessary

• Modifying administrative files to update the lists of file systems your computer shares or mounts automatically

• Checking the status of the network

• Diagnosing and fixing NFS-related problems as they arise

• Setting up maps for autofs

Remember, a computer can be both a server and a client—sharing local file systems with remote computers and mounting remote file systems.

Automatic File-System Sharing

Servers provide access to their file systems by sharing the file systems over the NFS environment. You specify which file systems are to be shared with the share command or the /etc/dfs/dfstab file.

Entries in the /etc/dfs/dfstab file are shared automatically whenever you start NFS server operation. You should set up automatic sharing if you need to share the same set of file systems on a regular basis. For example, if your computer is a server that supports home directories, you need to make the home directories available at all times. Most file-system sharing should be done automatically. The only time that manual sharing should occur is during testing or troubleshooting.

The dfstab file lists all the file systems that your server shares with its clients. This file also controls which clients can mount a file system. You can modify dfstab to add or delete a file system or change the way sharing is done. Just edit the file with any text editor that is supported (such as vi). The next time that the computer enters run level 3, the system reads the updated dfstab to determine which file systems should be shared automatically.

Each line in the dfstab file consists of a share command—the same command that you type at the command-line prompt to share the file system. The share command is located in /usr/sbin.

How to Set Up Automatic File-System Sharing

1. Become superuser or assume an equivalent role.

   For information about roles, see “Using Privileged Applications” in System Administration Guide: Security Services.

2. Add entries for each file system to be shared.

   Edit /etc/dfs/dfstab. Add one entry to the file for every file system that you want to be automatically shared. Each entry must be on a line by itself in the file and use this syntax:

   share [-F nfs] [-o specific-options] [-d description] pathname

   See the dfstab(4) man page for a description of /etc/dfs/dfstab and the share_nfs(1M) man page for a complete list of options.

3. Check if the NFS service is running on the server.

   If this is the first share command or set of share commands that you have initiated, the NFS service might not be running. Check that one of the NFS daemons is running by using the following command.

   # pgrep nfsd 318

   318 is the process ID for nfsd in this example. If an ID is not displayed, then the service is not running. The second daemon to check for is mountd.

4. (Optional) Start the NFS service.

   If the previous step does not report a process ID for nfsd, start the NFS service by using the following command.

   # /etc/init.d/nfs.server start

   This command ensures that NFS service is now running on the servers and restarts automatically when the server is at run level 3 during boot.

5. (Optional) Share the file system.

   After the entry is in /etc/dfs/dfstab, the file system can be shared by either rebooting the system or by using the shareall command. If the NFS service was started earlier, this command does not need to be run because the init script runs the command.

   # shareall

6. Verify that the information is correct.

   Run the share command to check that the correct options are listed:

   # share - /export/share/man ro "" - /usr/src rw=eng "" - /export/ftp ro,public ""

Where to Go From Here

The next step is to set up your autofs maps so that clients can access the file systems that you have shared on the server. See Task Overview for Autofs Administration.

How to Enable WebNFS Access

Starting with the 2.6 release, by default all file systems that are available for NFS mounting are automatically available for WebNFS access. The only condition that requires the use of this procedure is one of the following:

• To allow NFS mounting on a server that does not already allow NFS mounting

• To reset the public file handle to shorten NFS URLs by using the public option

• To force the loading of a specific html file by using the index option

See Planning for WebNFS Access for a list of issues that you should consider before starting the WebNFS service.

1. Become superuser or assume an equivalent role.

   For information about roles, see “Using Privileged Applications” in System Administration Guide: Security Services.

2. Add entries for each file system to be shared by using the WebNFS service.

   Edit /etc/dfs/dfstab. Add one entry to the file for every file system. The public and index tags that are shown in the following example are optional.

   share -F nfs -o ro,public,index=index.html /export/ftp

   See the dfstab(4) man page for a description of /etc/dfs/dfstab and the share_nfs(1M) man page for a complete list of options.

3. Check if the NFS service is running on the server.

   If this is the first share command or set of share commands that you have initiated, the NFS daemons might not be running. Check that one of the NFS daemons is running by using the following command.

   # pgrep nfsd 318

   318 is the process ID for nfsd in this example. If an ID is not displayed, then the service is not running. The second daemon to check for is mountd.

4. (Optional) Start the NFS service.

   If the previous step does not report a process ID for nfsd, start the NFS service by using the following command.

   # /etc/init.d/nfs.server start

   This command ensures that NFS service is now running on the servers and restarts automatically when the server is at run level 3 during boot.

5. (Optional) Share the file system.

   After the entry is in /etc/dfs/dfstab, the file system can be shared by either rebooting the system or by using the shareall command. If the NFS service was started earlier, this command does not need to be run because the script runs the command.

   # shareall

6. Verify that the information is correct.

   Run the share command to check that the correct options are listed:

   # share - /export/share/man ro "" - /usr/src rw=eng "" - /export/ftp ro,public,index=index.html ""

How to Enable NFS Server Logging

1. Become superuser or assume an equivalent role.

   For information about roles, see “Using Privileged Applications” in System Administration Guide: Security Services.

2. (Optional) Change file-system configuration settings.

   In /etc/nfs/nfslog.conf, you can change the settings in one of two ways. You can edit the default settings for all file systems by changing the data that is associated with the global tag. Alternately, you can add a new tag for this file system. If these changes are not needed, you do not need to change this file. The format of /etc/nfs/nfslog.conf is described in nfslog.conf(4).

3. Add entries for each file system to be shared by using NFS server logging.

   Edit /etc/dfs/dfstab. Add one entry to the file for the file system on which you are enabling NFS server logging. The tag that is used with the log=tag option must be entered in /etc/nfs/nfslog.conf. This example uses the default settings in the global tag.

   share -F nfs -o ro,log=global /export/ftp

   See the dfstab(4) man page for a description of /etc/dfs/dfstab and the share_nfs(1M) man page for a complete list of options.

4. Check if the NFS service is running on the server.

   If this is the first share command or set of share commands that you have initiated, the NFS daemons might not be running. Check that one of the NFS daemons is running by using the following command.

   # pgrep nfsd 318

   318 is the process ID for nfsd in this example. If an ID is not displayed, then the service is not running. The second daemon to check for is mountd.

5. (Optional) Start the NFS service.

   If the previous step does not report a process ID for nfsd, start the NFS service by using the following command.

   # /etc/init.d/nfs.server start

   This command ensures that NFS service is now running on the servers and restarts automatically when the server is at run level 3 during boot.

6. (Optional) Share the file system.

   After the entry is in /etc/dfs/dfstab, the file system can be shared by either rebooting the system or by using the shareall command. If the NFS service was started earlier, this command does not need to be run because the script runs the command.

   # shareall

7. Verify that the information is correct.

   Run the share command to check that the correct options are listed:

   # share - /export/share/man ro "" - /usr/src rw=eng "" - /export/ftp ro,log=global ""

8. (Optional) Start the NFS log daemon, nfslogd, if it is not running already.

   Restarting the NFS daemons by using the nfs.server script starts the daemon if the nfslog.conf file exists. Otherwise, the command needs to be run once by hand to create the files so that the command automatically restarts when the server is rebooted.

   # /usr/lib/nfs/nfslogd

Mounting File Systems

You can mount file systems in several ways. File systems can be mounted automatically when the system is booted, on demand from the command line, or through the automounter. The automounter provides many advantages to mounting at boot time or mounting from the command line. However, many situations require a combination of all three methods. Additionally, several ways of enabling or disabling processes exist, depending on the options you use when mounting the file system. See the following table for a complete list of the tasks that are associated with file-system mounting.

How to Mount a File System at Boot Time

If you want to mount file systems at boot time instead of using autofs maps, follow this procedure. This procedure must be completed on every client for remote file systems.

1. Become superuser or assume an equivalent role.

   For information about roles, see “Using Privileged Applications” in System Administration Guide: Security Services.

2. Add an entry for the file system to /etc/vfstab.

Entries in the /etc/vfstab file have the following syntax:

special  fsckdev  mountp  fstype  fsckpass  mount-at-boot  mntopts

See the vfstab(4) man page for more information.

NFS servers should not have NFS vfstab entries because of a potential deadlock. The NFS service is started after the entries in /etc/vfstab are checked. Consider the following. If two servers that are mounting file systems from each other fail at the same time, each system could hang as the systems reboot.

Example 14–1 Entry in the Client's vfstab File

You want a client machine to mount the /var/mail directory from the server wasp. You want the file system to be mounted as /var/mail on the client and you want the client to have read-write access. Add the following entry to the client's vfstab file.

wasp:/var/mail - /var/mail nfs - yes rw

How to Mount a File System From the Command Line

Mounting a file system from the command line is often done to test a new mount point. This type of mount allows for temporary access to a file system that is not available through the automounter.

1. Become superuser or assume an equivalent role.

   For information about roles, see “Using Privileged Applications” in System Administration Guide: Security Services.

2. Mount the file system.

   Type the following command:

   # mount -F nfs -o ro bee:/export/share/local /mnt

   In this instance, the /export/share/local file system from the server bee is mounted on read-only /mnt on the local system. Mounting from the command line allows for temporary viewing of the file system. You can unmount the file system with umount or by rebooting the local host.

   ---

   Caution –

   Starting with the 2.6 release, all versions of the mount command do not warn about invalid options. The command silently ignores any options that cannot be interpreted. To prevent unexpected behavior, ensure that you verify all of the options that were used.

   ---

Mounting With the Automounter

Task Overview for Autofs Administration includes the specific instructions for establishing and supporting mounts with the automounter. Without any changes to the generic system, clients should be able to access remote file systems through the /net mount point. To mount the /export/share/local file system from the previous example, you need to type the following:

% cd /net/bee/export/share/local

Because the automounter allows all users to mount file systems, root access is not required. The automounter also provides for automatic unmounting of file systems, so you do not need to unmount file systems after you are finished.

How to Disable Large Files on an NFS Server

For servers that are supporting clients that cannot handle a file over 2 GBytes, you might need to disable the ability to create large files.

Versions prior to 2.6 of the Solaris operating environment cannot use large files. If the clients need to access large files, check that the clients of the NFS server are running, at minimum, the 2.6 release.

1. Become superuser or assume an equivalent role.

   For information about roles, see “Using Privileged Applications” in System Administration Guide: Security Services.

2. Check that no large files exist on the file system.

   Here is an example of a command that you can run to locate large files:

   # cd /export/home1 # find . -xdev -size +2000000 -exec ls -l {} \;

   If large files are on the file system, you must remove or move these files to another file system.

3. Unmount the file system.

   # umount /export/home1

4. Reset the file system state if the file system has been mounted by using largefiles.

   fsck resets the file system state if no large files exist on the file system:

   # fsck /export/home1

5. Mount the file system by using nolargefiles.

   # mount -F ufs -o nolargefiles /export/home1

   You can mount from the command line, but to make the option more permanent, add an entry that resembles the following into /etc/vfstab:

   /dev/dsk/c0t3d0s1 /dev/rdsk/c0t3d0s1 /export/home1 ufs 2 yes nolargefiles

How to Use Client-Side Failover

1. Become superuser or assume an equivalent role.

   For information about roles, see “Using Privileged Applications” in System Administration Guide: Security Services.

2. On the NFS client, mount the file system by using the ro option.

   You can mount from the command line, through the automounter, or by adding an entry to /etc/vfstab that resembles the following:

   bee,wasp:/export/share/local - /usr/local nfs - no ro

   This syntax has been allowed by the automounter. However, the failover was not available while file systems were mounted, only when a server was being selected.

   ---

   Note –

   Servers that are running different versions of the NFS protocol cannot be mixed by using a command line or in a vfstab entry. Mixing servers that support NFS version 2 or version 3 protocols can only be done with autofs. In autofs, the best subset of version 2 or version 3 servers is used.

   ---

How to Disable Mount Access for One Client

1. Become superuser or assume an equivalent role.

   For information about roles, see “Using Privileged Applications” in System Administration Guide: Security Services.

2. Add an entry in /etc/dfs/dfstab.

   The first example allows mount access to all clients in the eng netgroup except the host that is named rose. The second example allows mount access to all clients in the eng.example.com DNS domain except for rose.

   share -F nfs -o ro=-rose:eng /export/share/man share -F nfs -o ro=-rose:.eng.example.com /export/share/man

   For additional information on access lists, see Setting Access Lists With the share Command. For a description of /etc/dfs/dfstab, see dfstab(4).

3. Share the file system.

   The NFS server does not use changes to /etc/dfs/dfstab until the file systems are shared again or until the server is rebooted.

   # shareall

How to Mount an NFS File System Through a Firewall

1. Become superuser or assume an equivalent role.

   For information about roles, see “Using Privileged Applications” in System Administration Guide: Security Services.

2. Manually mount the file system by using a command such as the following:

   # mount -F nfs bee:/export/share/local /mnt

   In this example, the file system /export/share/local is mounted on the local client by using the public file handle. An NFS URL can be used instead of the standard path name. If the public file handle is not supported by the server bee, the mount operation fails.

   ---

   Note –

   This procedure requires that the file system on the NFS server be shared by using the public option. Additionally, any firewalls between the client and the server must allow TCP connections on port 2049. Starting with the 2.6 release, all file systems that are shared allow for public file handle access, so the public option is applied by default.

   ---

How to Mount an NFS File System Using an NFS URL

1. Become superuser or assume an equivalent role.

   For information about roles, see “Using Privileged Applications” in System Administration Guide: Security Services.

2. (Optional) If you are using NFS version 2 or version 3, manually mount the file system by using a command such as the following:

   # mount -F nfs nfs://bee:3000/export/share/local /mnt

   In this example, the /export/share/local file system is being mounted from the server bee by using NFS port number 3000. The port number is not required and by default the standard NFS port number of 2049 is used. You can choose to include the public option with an NFS URL. Without the public option, the MOUNT protocol is used if the public file handle is not supported by the server. The public option forces the use of the public file handle, and the mount fails if the public file handle is not supported.

Setting Up NFS Services

This section describes some of the tasks necessary to do the following:

• Start and stop the NFS server

• Start and stop the automounter

How to Start the NFS Services

1. Become superuser or assume an equivalent role.

   For information about roles, see “Using Privileged Applications” in System Administration Guide: Security Services.

2. Enable the NFS service daemons.

   Type the following command:

   # /etc/init.d/nfs.server start

   This command starts the daemons if an entry is in /etc/dfs/dfstab.

How to Stop the NFS Services

1. Become superuser or assume an equivalent role.

   For information about roles, see “Using Privileged Applications” in System Administration Guide: Security Services.

2. Disable the NFS service daemons.

   Type the following command:

   # /etc/init.d/nfs.server stop

How to Start the Automounter

1. Become superuser or assume an equivalent role.

   For information about roles, see “Using Privileged Applications” in System Administration Guide: Security Services.

2. Enable the autofs daemon.

   Type the following command:

   # /etc/init.d/autofs start

How to Stop the Automounter

1. Become superuser or assume an equivalent role.

   For information about roles, see “Using Privileged Applications” in System Administration Guide: Security Services.

2. Disable the autofs daemon.

   Type the following command:

   # /etc/init.d/autofs stop

Administering the Secure NFS System

To use the Secure NFS system, all the computers that you are responsible for must have a domain name. A domain is an administrative entity—typically, several computers—that is part of a larger network. If you are running a name service, you should also establish the name service for the domain. See System Administration Guide: Naming and Directory Services (FNS and NIS+).

Kerberos V5 authentication is supported by the NFS service. “Introduction to SEAM” in System Administration Guide: Security Services discusses the Kerberos service.

You can also configure the Secure NFS environment to use Diffie-Hellman authentication. “Using Authentication Services (Tasks)” in System Administration Guide: Security Services discusses this authentication service.

How to Set Up a Secure NFS Environment With DH Authentication

1. Assign your domain a domain name, and make the domain name known to each computer in the domain.

   See the System Administration Guide: Naming and Directory Services (FNS and NIS+) if you are using NIS+ as your name service.

2. Establish public keys and secret keys for your clients' users by using the newkey or nisaddcred command. Have each user establish his or her own secure RPC password by using the chkey command.

   ---

   Note –

   For information about these commands, see the newkey(1M), the nisaddcred(1M), and the chkey(1) man pages.

   ---

   When public keys and secret keys have been generated, the public keys and encrypted secret keys are stored in the publickey database.

3. Verify that the name service is responding. If you are running NIS+, type the following:

   # nisping -u Last updates for directory eng.acme.com. : Master server is eng-master.acme.com. Last update occurred at Mon Jun 5 11:16:10 1995 Replica server is eng1-replica-replica-58.acme.com. Last Update seen was Mon Jun 5 11:16:10 1995

   If you are running NIS, verify that the ypbind daemon is running.

4. Verify that the keyserv daemon of the key server is running.

   Type the following command.

   # ps -ef | grep keyserv root 100 1 16 Apr 11 ? 0:00 /usr/sbin/keyserv root 2215 2211 5 09:57:28 pts/0 0:00 grep keyserv

   If the daemon isn't running, start the key server by typing the following:

   # /usr/sbin/keyserv

5. Decrypt and store the secret key.

   Usually, the login password is identical to the network password. In this situation, keylogin is not required. If the passwords are different, the users have to log in, and then do a keylogin. You still need to use the keylogin -r command as root to store the decrypted secret key in /etc/.rootkey.

   ---

   Note –

   You need to run keylogin -r if the root secret key changes or /etc/.rootkey is lost.

   ---

6. Update mount options for the file system.

   For Diffie-Hellman authentication, edit the /etc/dfs/dfstab file and add the sec=dh option to the appropriate entries.

   share -F nfs -o sec=dh /export/home

   See the dfstab(4) man page for a description of /etc/dfs/dfstab.

7. Update the automounter maps for the file system.

   Edit the auto_master data to include sec=dh as a mount option in the appropriate entries for Diffie-Hellman authentication:

   /home auto_home -nosuid,sec=dh

   ---

   Note –

   Releases through Solaris 2.5 have a limitation. If a client does not securely mount a shared file system that is secure, users have access as nobody, rather than as themselves. For subsequent releases that use version 2, the NFS server refuses access if the security modes do not match, unless -sec=none is included on the share command line. With version 3, the mode is inherited from the NFS server, so clients do not need to specify sec=dh. The users have access to the files as themselves.

   ---

   When you reinstall, move, or upgrade a computer, remember to save /etc/.rootkey if you do not establish new keys or change the keys for root. If you do delete /etc/.rootkey, you can always type the following:

   # keylogin -r

WebNFS Administration Tasks

This section provides instructions for administering the WebNFS system. Related tasks follow.

Planning for WebNFS Access

To use WebNFS, you first need an application that is capable of running and loading an NFS URL (for example, nfs://server/path). The next step is to choose the file system that can be exported for WebNFS access. If the application is web browsing, often the document root for the web server is used. You need to consider several factors when choosing a file system to export for WebNFS access.

1. Each server has one public file handle that by default is associated with the server's root file system. The path in an NFS URL is evaluated relative to the directory with which the public file handle is associated. If the path leads to a file or directory within an exported file system, the server provides access. You can use the public option of the share command to associate the public file handle with a specific exported directory. Using this option allows URLs to be relative to the shared file system rather than to the server's root file system. The root file system does not allow web access unless the root file system is shared.

2. The WebNFS environment enables users who already have mount privileges to access files through a browser. This capability is enabled regardless of whether the file system is exported by using the public option. Because users already have access to these files through the NFS setup, this access should not create any additional security risk. You only need to share a file system by using the public option if users who cannot mount the file system need to use WebNFS access.

3. File systems that are already open to the public make good candidates for using the public option. Some examples are the top directory in an ftp archive or the main URL directory for a web site.

4. You can use the index option with the share command to force the loading of an HTML file. Otherwise, you can list the directory when an NFS URL is accessed.

   After a file system is chosen, review the files and set access permissions to restrict viewing of files or directories, as needed. Establish the permissions, as appropriate, for any NFS file system that is being shared. For many sites, 755 permissions for directories and 644 permissions for files provide the correct level of access.

   You need to consider additional factors if both NFS and HTTP URLs are to be used to access one web site. These factors are described in WebNFS Limitations With Web Browser Use.

How to Browse Using an NFS URL

Browsers that are capable of supporting the WebNFS service should provide access to an NFS URL that resembles the following:

nfs://server<:port>/path

server

Name of the file server

port

Port number to use (2049, default value)

path

Path to file, which can be relative to the public file handle or to the root file system

In most browsers, the URL service type (for example, nfs or http) is remembered from one transaction to the next. The exception occurs when a URL that includes a different service type is loaded. After you use an NFS URL, a reference to an HTTP URL might be loaded. If so, subsequent pages are loaded by using the HTTP protocol instead of the NFS protocol.

How to Enable WebNFS Access Through a Firewall

You can enable WebNFS access for clients that are not part of the local subnet by configuring the firewall to allow a TCP connection on port 2049. Just allowing access for httpd does not allow NFS URLs to be used.

Task Overview for Autofs Administration

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. To perform the tasks that are discussed in this section, use the Solaris Management Console tools or see the System Administration Guide: Naming and Directory Services (FNS and NIS+) .

Task Map for Autofs Administration

The following table provides a description and a pointer to many of the tasks that are related to autofs.

Administrative Tasks Involving Maps

The following tables describe several of the factors you need to be aware of when administering autofs maps. Which type of map and which name service you choose change the mechanism that you need to use to make changes to the autofs maps.

The following table describes the types of maps and their uses.

The following table describes how to make changes to your autofs environment that are based on your name service.

The next table tells you when to run the automount command, depending on the modification you have made to the type of map. For example, if you have made an addition or a deletion to a direct map, you need to run the automount command on the local system. By running the command, you make the change effective. However, if you have modified an existing entry, you do not need to run the automount command for the change to become effective.

Modifying the Maps

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

How to Modify the Master Map

1. Log in as a user who has permissions to change the maps.

2. Using the nistbladm command, make your changes to the master map.

   See the System Administration Guide: Naming and Directory Services (FNS and NIS+).

3. For each client, become superuser or assume an equivalent role.

   For information about roles, see “Using Privileged Applications” in System Administration Guide: Security Services.

4. For each client, run the automount command to ensure that your changes become effective.

5. 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 gathers information from the master map whenever it is run.

How to Modify Indirect Maps

Log in as a user who has permissions to change the maps.

Using the nistbladm command, make your changes to the indirect map.

See the System Administration Guide: Naming and Directory Services (FNS and NIS+).

The change becomes effective the next time that the map is used, which is the next time a mount is done.

How to Modify Direct Maps

1. Log in as a user who has permissions to change the maps.

2. Using the nistbladm command, add or delete your changes to the direct map.

   See the System Administration Guide: Naming and Directory Services (FNS and NIS+).

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

4. Notify your users of the changes.

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

   ---

   Note –

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

   ---

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

   ---

   Note –

   Use indirect maps whenever possible. Indirect maps are easier to construct and less demanding on the computers' file systems. Also, indirect maps do not occupy as much space in the mount table as direct maps.

   ---

Avoiding Mount-Point Conflicts

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

You need to mount the partition in some other location, for example, on /export/src. You then need an entry in /etc/vfstab such as the following:

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

You also need this entry in auto_src:

terra		terra:/export/src 

terra is the name of the computer.

Accessing Non-NFS File Systems

Autofs can also mount files other than NFS files. Autofs mounts files on removable media, such as diskettes or CD-ROM. Normally, you would mount files on removable media by using the Volume Manager. The following examples show how this mounting could be accomplished 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 the file system from the map. If you plan to access non-NFS file systems and you are using autofs, see the following procedures.

How to Access CD-ROM Applications With Autofs

Use this procedure if you are not using Volume Manager.

1. Become superuser or assume an equivalent role.

   For information about roles, see “Using Privileged Applications” in System Administration Guide: Security Services.

2. Update the autofs map.

   Add an entry for the CD-ROM file system, which should resemble the following:

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

   The CD-ROM device that you intend to mount must appear as a name that follows the colon.

How to Access PC-DOS Data Diskettes With Autofs

Use this procedure if you are not using Volume Manager.

1. Become superuser or assume an equivalent role.

   For information about roles, see “Using Privileged Applications” in System Administration Guide: Security Services.

2. Update the autofs map.

   Add an entry for the diskette file system such as the following:

   pcfs -fstype=pcfs :/dev/diskette

Accessing NFS File Systems Using CacheFS

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

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

How to Access NFS File Systems Using CacheFS

1. Become superuser or assume an equivalent role.

   For information about roles, see “Using Privileged Applications” in System Administration Guide: Security Services.

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

   # cfsadmin -c /var/cache

3. Add the cachefs entry to the appropriate automounter map.

   For example, adding this entry to the master map caches all home directories:

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

   Adding this entry to the auto_home map only caches the home directory for the user who is named rich:

   rich -fstype=cachefs,cachedir=/var/cache,backfstype=nfs dragon:/export/home1/rich

   ---

   Note –

   Options that are included in maps that are searched later override options set in maps that are searched earlier. The last options that are found are the ones that are used. In the previous example, an additional entry to the auto_home map only needs to include the options in the master maps if some options required changes.

   ---

Customizing the Automounter

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

Setting Up a Common View of /home

The ideal is for all network users to be able to locate their own or anyone'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

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, 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. Without this restriction, any user could have superuser privileges on any computer.

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

1. Become superuser or assume an equivalent role.

   For information about roles, see “Using Privileged Applications” in System Administration Guide: Security Services.

2. Install home directory partitions under /export/home.

   If the system has several partitions, install the partitions under separate directories, for example, /export/home1, /export/home2, and so on.

3. Use the Solaris Management Console tools to create and maintain the auto_home map.

   Whenever you create a new user account, type the location of the user's home directory in the auto_home map. Map entries can be simple, for example:

   rusty dragon:/export/home1/& gwenda dragon:/export/home1/& charles sundog:/export/home2/& rich dragon:/export/home3/&

   Notice the use of the & (ampersand) to substitute the map key. The ampersand 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. 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.

   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. Other users can continue to use the /home/rusty path.

How to Consolidate Project-Related Files Under /ws

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

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

   /ws auto_ws -nosuid

   The auto_ws map determines the contents of the /ws directory.

2. Add the -nosuid option as a precaution.

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

3. 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 resembles the following:

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

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

   compiler alpha:/export/ws/compiler

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

   Modify the entries in the map as follows:

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

   Although the map now appears to be much larger, the map still contains only the five entries. Each entry is larger because each entry 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 informs autofs that the entry is continued onto the next line. Effectively, the entry is one long line, though line breaks and some indenting have been used to make the entry more readable. The tools directory contains software development tools for all subprojects, so this directory 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 typically consume substantial amounts of disk space. Through the life of the project, you might be required to relocate and expand various disk partitions. If these changes are reflected in the auto_ws map, the users do not need to be notified, as the directory hierarchy under /ws is not changed.

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

How to Set Up Different Architectures to Access a Shared Namespace

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

1. Create the auto_local map with the nistbladm command.

   See the System Administration Guide: Naming and Directory Services (FNS and NIS+).

2. Choose a single, site-specific name for the shared namespace. This name makes the files and directories that belong to this space easily identifiable.

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

3. For ease of user community recognition, create an autofs indirect map. Mount this map at /usr/local. Set up the following entry in the NIS+ (or NIS) auto_master map:

   /usr/local auto_local -ro

   Notice that the -ro mount option implies that clients cannot write to any files or directories.

4. Export the appropriate directory on the server.

5. Include a bin entry in the auto_local map.

   Your directory structure resembles the following:

   bin aa:/export/local/bin

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

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

   • For SPARC clients – Place executables in /export/local/bin/sparc.

   • For IA clients – Place executables in /export/local/bin/i386.

How to Support Incompatible Client Operating System Versions

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

   You can combine the autofs OSREL variable 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 clients that are running version 5.6 of the operating system, export the following file systems:

   • For SPARC clients – Export /export/local/bin/sparc5.6.

   • For IA clients – Place executables in /export/local/bin/i3865.6.

How to Replicate Shared Files Across Several Servers

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

1. Become superuser or assume an equivalent role.

   For information about roles, see “Using Privileged Applications” in System Administration Guide: Security Services.

2. Modify the entry in the autofs maps.

   Create the list of all replica servers as a comma-separated list, such as the following:

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

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

How to Apply Autofs Security Restrictions

1. Become superuser or assume an equivalent role.

   For information about roles, see “Using Privileged Applications” in System Administration Guide: Security Services.

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

   /home auto_home -nosuid

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

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

   ---

   Note –

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

   ---

How to Use a Public File Handle With Autofs

1. Become superuser or assume an equivalent role.

   For information about roles, see “Using Privileged Applications” in System Administration Guide: Security Services.

2. Create an entry in the autofs map such as the following:

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

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

How to Use NFS URLs With Autofs

1. Become superuser or assume an equivalent role.

   For information about roles, see “Using Privileged Applications” in System Administration Guide: Security Services.

2. Create an autofs entry such as the following:

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

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

Disabling Autofs Browsability

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

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

How to Completely Disable Autofs Browsability on a Single NFS Client

1. Become superuser or assume an equivalent role on the NFS client.

   For information about roles, see “Using Privileged Applications” in System Administration Guide: Security Services.

2. Perform either of the following steps.

   1. (Optional) If you are using the Solaris 9 release or an earlier release, 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 autmountd daemon:.

      /usr/lib/autofs/automountd -n \ < /dev/null > /dev/console 2>&1 # start daemon

3. Restart the autofs service.

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

How to Disable Autofs Browsability for All Clients

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

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

   /home auto_home -nobrowse

2. Run the automount command on all clients.

   The new behavior becomes effective after you run the automount command on the client systems or after a reboot.

   # /usr/sbin/automount

How to Disable Autofs Browsability on a Selected File System

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

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

   For local file entries to have precedence, the entry in the name service switch file should list files before the name service. For example:

   automount: files nisplus

   This entry shows the default configuration in a standard Solaris installation.

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

   For additions to the local files to have precedence over the entries in the namespace, the +auto_master entry must be moved to follow /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 placement prevents any local changes from being used.

3. Add the nobrowse option to the /net entry in the /etc/auto_master file.

   /net -hosts -nosuid,nobrowse

4. On all clients, run the automount command.

   The new behavior becomes effective after running the automount command on the client systems or after a reboot.

   # /usr/sbin/automount

Strategies for NFS Troubleshooting

When tracking down an NFS problem, remember the main points of possible failure: the server, the client, and the network. The strategy that is outlined in this section tries to isolate each individual component to find the one that is not working. In all situations, the mountd and nfsd daemons must be running on the server in order for remote mounts to succeed.

The mountd and nfsd daemons start automatically at boot time only if NFS share entries are in the /etc/dfs/dfstab file. Therefore, you must start mountd and nfsd manually when you set up sharing for the first time.

The -intr option is set by default for all mounts. If a program hangs with a “server not responding” message, you can kill the program with the keyboard interrupt Control-c.

When the network or server has problems, programs that access hard-mounted remote files fail differently than those programs that access soft-mounted remote files. Hard-mounted remote file systems cause the client's kernel to retry the requests until the server responds again. Soft-mounted remote file systems cause the client's system calls to return an error after trying for awhile. Because these errors can result in unexpected application errors and data corruption, avoid soft mounting.

When a file system is hard mounted, a program that tries to access the file system hangs if the server fails to respond. In this situation, the NFS system displays the following message on the console:

NFS server hostname not responding still trying

When the server finally responds, the following message appears on the console:

NFS server hostname ok

A program that accesses a soft-mounted file system whose server is not responding generates the following message:

NFS operation failed for server hostname: error # (error_message)

Because of possible errors, do not soft-mount file systems with read-write data or file systems from which executables are run. Writable data could be corrupted if the application ignores the errors. Mounted executables might not load properly and can fail.

NFS Troubleshooting Procedures

To determine where the NFS service has failed, you need to follow several procedures to isolate the failure. Check for the following items:

• Can the client reach the server?

• Can the client contact the NFS services on the server?

• Are the NFS services running on the server?

In the process of checking these items, you might notice that other portions of the network are not functioning. For example, the name service or the physical network hardware might not be functioning. The System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP) contains debugging procedures for several name services. Also, during the process you might see that the problem is not at the client end. An example is if you get at least one trouble call from every subnet in your work area. In this situation, you should assume that the problem is the server or the network hardware near the server. So, you should start the debugging process at the server, not at the client.

How to Check Connectivity on an NFS Client

1. Check that the NFS server is reachable from the client. On the client, type the following command.

   % /usr/sbin/ping bee bee is alive

   If the command reports that the server is alive, remotely check the NFS server. See How to Check the NFS Server Remotely.

2. If the server is not reachable from the client, ensure that the local name service is running.

   For NIS+ clients, type the following:

   % /usr/lib/nis/nisping -u Last updates for directory eng.acme.com. : Master server is eng-master.acme.com. Last update occurred at Mon Jun 5 11:16:10 1995 Replica server is eng1-replica-58.acme.com. Last Update seen was Mon Jun 5 11:16:10 1995

3. If the name service is running, ensure that the client has received the correct host information by typing the following:

   % /usr/bin/getent hosts bee 129.144.83.117 bee.eng.acme.com

4. If the host information is correct, but the server is not reachable from the client, run the ping command from another client.

   If the command run from a second client fails, see How to Verify the NFS Service on the Server.

5. If the server is reachable from the second client, use ping to check connectivity of the first client to other systems on the local net.

   If this command fails, check the networking software configuration on the client (/etc/netmasks, /etc/nsswitch.conf, and so forth).

6. If the software is correct, check the networking hardware.

   Try moving the client onto a second net drop.

How to Check the NFS Server Remotely

1. Check that the NFS services have started on the NFS server by typing the following command:

   % rpcinfo -s bee|egrep 'nfs|mountd' 100003 3,2 tcp,udp,tcp6,upd6 nfs superuser 100005 3,2,1 ticots,ticotsord,tcp,tcp6,ticlts,udp,upd6 mountd superuser

   If the daemons have not been started, see How to Restart NFS Services.

2. Check that the server's nfsd processes are responding.

   On the client, type the following command to test the UDP NFS connections from the server.

   % /usr/bin/rpcinfo -u bee nfs program 100003 version 2 ready and waiting program 100003 version 3 ready and waiting

   If the server is running, it prints a list of program and version numbers. Using the -t option tests the TCP connection. If this command fails, proceed to How to Verify the NFS Service on the Server.

3. Check that the server's mountd is responding, by typing the following command.

   % /usr/bin/rpcinfo -u bee mountd program 100005 version 1 ready and waiting program 100005 version 2 ready and waiting program 100005 version 3 ready and waiting

   If the server is running, it prints a list of program and version numbers that are associated with the UDP protocol. Using the -t option tests the TCP connection. If either attempt fails, proceed to How to Verify the NFS Service on the Server.

4. Check the local autofs service if it is being used:

   % cd /net/wasp

   Choose a /net or /home mount point that you know should work properly. If this command fails, then as root on the client, type the following to restart the autofs service:

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

5. Verify that file system is shared as expected on the server.

   % /usr/sbin/showmount -e bee /usr/src eng /export/share/man (everyone)

   Check the entry on the server and the local mount entry for errors. Also, check the namespace. In this instance, if the first client is not in the eng netgroup, that client cannot mount the /usr/src file system.

   Check all entries that include mounting information in all of the local files. The list includes /etc/vfstab and all the /etc/auto_* files.

How to Verify the NFS Service on the Server

1. Become superuser or assume an equivalent role.

   For information about roles, see “Using Privileged Applications” in System Administration Guide: Security Services.

2. Check that the server can reach the clients.

   # ping lilac lilac is alive

3. If the client is not reachable from the server, ensure that the local name service is running. For NIS+ clients, type the following:

   % /usr/lib/nis/nisping -u Last updates for directory eng.acme.com. : Master server is eng-master.acme.com. Last update occurred at Mon Jun 5 11:16:10 1995 Replica server is eng1-replica-58.acme.com. Last Update seen was Mon Jun 5 11:16:10 1995

4. If the name service is running, check the networking software configuration on the server (/etc/netmasks, /etc/nsswitch.conf, and so forth).

5. Type the following command to check whether the rpcbind daemon is running.

   # /usr/bin/rpcinfo -u localhost rpcbind program 100000 version 1 ready and waiting program 100000 version 2 ready and waiting program 100000 version 3 ready and waiting

   If the server is running, it prints a list of program and version numbers that are associated with the UDP protocol. If rpcbind seems to be hung, either reboot the server or follow the steps in How to Warm-Start rpcbind.

6. Type the following command to check whether the nfsd daemon is running.

   # rpcinfo -u localhost nfs program 100003 version 2 ready and waiting program 100003 version 3 ready and waiting # ps -ef | grep nfsd root 232 1 0 Apr 07 ? 0:01 /usr/lib/nfs/nfsd -a 16 root 3127 2462 1 09:32:57 pts/3 0:00 grep nfsd

   If the server is running, it prints a list of program and version numbers that are associated with the UDP protocol. Also use the -t option with rpcinfo to check the TCP connection. If these commands fail, restart the NFS service. See How to Restart NFS Services.

7. Type the following command to check whether the mountd daemon is running.

   # /usr/bin/rpcinfo -u localhost mountd program 100005 version 1 ready and waiting program 100005 version 2 ready and waiting program 100005 version 3 ready and waiting # ps -ef | grep mountd root 145 1 0 Apr 07 ? 21:57 /usr/lib/autofs/automountd root 234 1 0 Apr 07 ? 0:04 /usr/lib/nfs/mountd root 3084 2462 1 09:30:20 pts/3 0:00 grep mountd

   If the server is running, it prints a list of program and version numbers that are associated with the UDP protocol. Also use the -t option with rpcinfo to check the TCP connection. If these commands fail, restart the NFS service. See How to Restart NFS Services.

How to Restart NFS Services

1. Become superuser or assume an equivalent role.

   For information about roles, see “Using Privileged Applications” in System Administration Guide: Security Services.

2. To enable daemons without rebooting, type the following commands.

# /etc/init.d/nfs.server stop
# /etc/init.d/nfs.server start

This remedy stops and restarts the daemons if an entry is in /etc/dfs/dfstab.

How to Warm-Start rpcbind

If the NFS server cannot be rebooted because of work in progress, you can restart rpcbind without having to restart all of the services that use RPC. Just complete a warm start as described in this procedure.

1. Become superuser or assume an equivalent role.

   For information about roles, see “Using Privileged Applications” in System Administration Guide: Security Services.

2. Determine the PID for rpcbind.

   Run ps to get the PID, which is the value in the second column.

   # ps -ef |grep rpcbind root 115 1 0 May 31 ? 0:14 /usr/sbin/rpcbind root 13000 6944 0 11:11:15 pts/3 0:00 grep rpcbind

3. Send a SIGTERM signal to the rpcbind process.

   In this example, term is the signal that is to be sent and 115 is the PID for the program (see the kill(1) man page). This command causes rpcbind to create a list of the current registered services in /tmp/portmap.file and /tmp/rpcbind.file.

   # kill -s term 115

   ---

   Note –

   If you do not kill the rpcbind process with the -s term option, you cannot complete a warm start of rpcbind. You must reboot the server to restore service.

   ---

4. Restart rpcbind.

   Warm-restart the command so that the files that were created by the kill command are consulted. A warm-start also ensures that the process resumes without requiring a restart of all of the RPC services. See the rpcbind(1M) man page.

   # /usr/sbin/rpcbind -w

Identifying Which Host Is Providing NFS File Service

Run the nfsstat command with the -m option to gather current NFS information. The name of the current server is printed after “currserver=”.

% nfsstat -m
/usr/local from bee,wasp:/export/share/local
 Flags: vers=3,proto=tcp,sec=sys,hard,intr,llock,link,synlink,
		acl,rsize=32768,wsize=32678,retrans=5
 Failover: noresponse=0, failover=0, remap=0, currserver=bee

How to Verify Options Used With the mount Command

In the Solaris 2.6 release and in any versions of the mount command that were patched after the 2.6 release, no warning is issued for invalid options. The following procedure helps determine whether the options that were supplied either on the command line or through /etc/vfstab were valid.

For this example, assume that the following command has been run:

# mount -F nfs -o ro,vers=2 bee:/export/share/local /mnt

1. Verify the options by running the following command.

   % nfsstat -m /mnt from bee:/export/share/local Flags: vers=2,proto=tcp,sec=sys,hard,intr,dynamic,acl,rsize=8192,wsize=8192, retrans=5

   The file system from bee has been mounted with the protocol version set to 2. Unfortunately, the nfsstat command does not display information about all of the options. However, using the nfsstat command is the most accurate way to verify the options.

2. Check the entry in /etc/mnttab.

   The mount command does not allow invalid options to be added to the mount table. Therefore, verify that the options that are listed in the file match those options that are listed on the command line. In this way, you can check those options that are not reported by the nfsstat command.

   # grep bee /etc/mnttab bee:/export/share/local /mnt nfs ro,vers=2,dev=2b0005e 859934818

Troubleshooting Autofs

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

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

• Error messages that are generated by the verbose (-v) option of automount

• Error messages that might appear at any time

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

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

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

Error Messages Generated by automount -v

bad key key in direct map mapname

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

bad key key in indirect map mapname

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

can't mount server:pathname: reason

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

couldn't create mount point mountpoint: reason

Autofs was unable to create a mount point that was required for a mount. This problem most frequently occurs when you attempt 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, which means the file system cannot be exported. The mount point cannot be created because the exported parent file system is exported read-only.

leading space in map entry entry text in mapname

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

fake /blat frobz:/usr/frotz

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

mapname: Not found

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

remount server:pathname on mountpoint: server not responding

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

WARNING: mountpoint already mounted on

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

Miscellaneous Error Messages

dir mountpoint must start with '/'

The automounter mount point must be given as a full path name. Check the spelling and path name of the mount point.

hierarchical mountpoints: pathname1 and pathname2

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

host server not responding

Autofs attempted to contact server, but received no response.

hostname: exports: rpc_err

An error occurred while getting the export list from hostname. This message indicates a server or network problem.

map mapname, key key: bad

The map entry is malformed, and autofs cannot interpret the entry. Recheck the entry. Perhaps the entry has characters that need escaping.

mapname: nis_err

An error occurred when looking up an entry in a NIS map. This message can indicate NIS problems.

mount of server:pathname on mountpoint:reason

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

mountpoint: Not a directory

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

nfscast: cannot send packet: reason

Autofs cannot send a query packet to a server in a list of replicated file system locations.

nfscast: cannot receive reply: reason

Autofs cannot receive replies from any of the servers in a list of replicated file system locations.

nfscast: select: reason

All these error messages indicate problems in attempting to ping servers for a replicated file system. This message can indicate a network problem.

pathconf: no info for server:pathname

Autofs failed to get pathconf information for the path name (see the fpathconf(2) man page).

pathconf: server: server not responding

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

Other Errors With Autofs

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

/etc/auto_home: +auto_home: not found

In this situation, the auto_home file has incorrect permissions. Each entry in the file generates an error message that is similar to this message. The permissions to the file should be reset by typing the following command:

# chmod 644 /etc/auto_home

NFS Error Messages

This section shows an error message that is followed by a description of the conditions that should create the error and at minimum one remedy.

Bad argument specified with index option - must be a file

You must include a file name with the index option. You cannot use directory names.

Cannot establish NFS service over /dev/tcp: transport setup problem

This message is often created when the services information in the namespace has not been updated. The message can also be reported for UDP. To fix this problem, you must update the services data in the namespace. For NIS+, the entries should be as follows:

nfsd nfsd tcp 2049 NFS server daemon nfsd nfsd udp 2049 NFS server daemon

For NIS and /etc/services, the entries should be as follows:

nfsd 2049/tcp nfs # NFS server daemon nfsd 2049/udp nfs # NFS server daemon

Cannot use index option without public option

Include the public option with the index option in the share command. You must define the public file handle in order for the index option to work.

---

Note –

The Solaris 2.5.1 release required that the public file handle be set by using the share command. A change in the Solaris 2.6 release sets the public file handle to be root (/) by default. This error message is no longer relevant.

---

Could not start daemon: error

This message is displayed if the daemon terminates abnormally or if a system call error occurs. The error string defines the problem.

Could not use public filehandle in request to server

This message is displayed if the public option is specified but the NFS server does not support the public file handle. In this situation, the mount fails. To remedy this situation, either try the mount request without using the public file handle or reconfigure the NFS server to support the public file handle.

daemon running already with pid pid

The daemon is already running. If you want to run a new copy, kill the current version and start a new version.

error locking lock file

This message is displayed when the lock file that is associated with a daemon cannot be locked properly.

error checking lock file: error

This message is displayed when the lock file that is associated with a daemon cannot be opened properly.

NOTICE: NFS3: failing over from host1 to host2

This message is displayed on the console when a failover occurs. The message is advisory only.

filename: File too large

An NFS version 2 client is trying to access a file that is over 2 Gbytes.

mount: ... server not responding:RPC_PMAP_FAILURE - RPC_TIMED_OUT

The server that is sharing the file system you are trying to mount is down or unreachable, at the wrong run level, or its rpcbind is dead or hung.

mount: ... server not responding: RPC_PROG_NOT_REGISTERED

The mount request registered with rpcbind, but the NFS mount daemon mountd is not registered.

mount: ... No such file or directory

Either the remote directory or the local directory does not exist. Check the spelling of the directory names. Run ls on both directories.

mount: ...: Permission denied

Your computer name might not be in the list of clients or netgroup that is allowed access to the file system you tried to mount. Use showmount -e to verify the access list.

NFS fsstat failed for server hostname: RPC: Authentication error

This error can be caused by many situations. One of the most difficult situations to debug is when this problem occurs because a user is in too many groups. Currently, a user can be in up to 16 groups but no more if the user is accessing files through NFS mounts. An alternate does exist for users who need to be in more than 16 groups. You can use access control lists to provide the needed access privileges, if you run at minimum the Solaris 2.5 release on the NFS server and the NFS clients.

nfs mount: ignoring invalid option “-option”

The -option flag is not valid. Refer to the mount_nfs(1M) man page to verify the required syntax.

---

Note –

This error message is not displayed when running any version of the mount command that is included in a Solaris release from 2.6 to the current release or in earlier versions that have been patched.

---

nfs mount: NFS can't support “nolargefiles”

An NFS client has attempted to mount a file system from an NFS server by using the -nolargefiles option. This option is not supported for NFS file system types.

nfs mount: NFS V2 can't support “largefiles”

The NFS version 2 protocol cannot handle large files. You must use version 3 if access to large files is required.

NFS server hostname not responding still trying

If programs hang while doing file-related work, your NFS server might have failed. This message indicates that NFS server hostname is down or that a problem has occurred with the server or the network. If failover is being used, hostname is a list of servers. Start troubleshooting with How to Check Connectivity on an NFS Client.

port number in nfs URL not the same as port number in port option

The port number that is included in the NFS URL must match the port number that is included with the -port option to mount. If the port numbers do not match, the mount fails. Either change the command to make the port numbers identical or do not specify the port number that is incorrect. Usually, you do not need to specify the port number in the NFS URL and with the -port option.

replicas must have the same version

For NFS failover to function properly, the NFS servers that are replicas must support the same version of the NFS protocol. Mixing versions is not allowed.

replicated mounts must be read-only

NFS failover does not work on file systems that are mounted read-write. Mounting the file system read-write increases the likelihood that a file could change. NFS failover depends on the file systems being identical.

replicated mounts must not be soft

Replicated mounts require that you wait for a timeout before failover occurs. The soft option requires that the mount fail immediately when a timeout starts, so you cannot include the -soft option with a replicated mount.

share_nfs: Cannot share more than one filesystem with 'public' option

Check that the /etc/dfs/dfstab file has only one file system selected to be shared with the -public option. Only one public file handle can be established per server, so only one file system per server can be shared with this option.

WARNING: No network locking on hostname:path: contact admin to install server change

An NFS client has unsuccessfully attempted to establish a connection with the network lock manager on an NFS server. Rather than fail the mount, this warning is generated to warn you that locking does not work.

Chapter 15 Accessing Network File Systems (Reference)

This chapter provides an introduction to the NFS commands, as well as information about all of the pieces of the NFS environment and how these pieces work together.

• NFS Files

• NFS Daemons

• NFS Commands

• Other Useful Commands

• How the NFS Service Works

• Autofs Maps

• How Autofs Works

• Autofs Reference

NFS Files

You need several files to support NFS activities on any computer. Many of these files are ASCII, but some of the files are data files. Table 15–1 lists these files and their functions.

The first entry in /etc/dfs/fstypes is often used as the default file-system type for remote file systems. This entry defines the NFS file-system type as the default.

Only one entry is in /etc/default/fs: the default file-system type for local disks. You can determine the file-system types that are supported on a client or server by checking the files in /kernel/fs.

/etc/default/nfslogd File

This file defines some of the parameters that are used when using NFS server logging. The following parameters can be defined.

CYCLE_FREQUENCY

Determines the number of hours that must pass before the log files are cycled. The default value is 24 hours. This option is used to prevent the log files from growing too large.

IDLE_TIME

Sets the number of seconds nfslogd should sleep before checking for more information in the buffer file. This parameter also determines how often the configuration file is checked. This parameter, along with MIN_PROCESSING_SIZE, determines how often the buffer file is processed. The default value is 300 seconds. Increasing this number can improve performance by reducing the number of checks.

MAPPING_UPDATE_INTERVAL

Specifies the number of seconds between updates of the records in the file-handle-to-path mapping tables. The default value is 86400 seconds or one day. This parameter helps keep the file-handle-to-path mapping tables up-to-date without having to continually update the tables.

MAX_LOGS_PRESERVE

Determines the number of log files to be saved. The default value is 10.

MIN_PROCESSING_SIZE

Sets the minimum number of bytes that the buffer file must reach before processing and writing to the log file. This parameter, along with IDLE_TIME, determines how often the buffer file is processed. The default value is 524288 bytes. Increasing this number can improve performance by reducing the number of times the buffer file is processed.

PRUNE_TIMEOUT

Selects the number of hours that must pass before a file-handle-to-path mapping record times out and can be pruned. The default value is 168 hours or 7 days.

UMASK

Specifies the file mode creation mask for the log files that are created by nfslogd. The default value is 0137.

/etc/nfs/nfslog.conf File

This file defines the path, file names, and type of logging to be used by nfslogd. Each definition is associated with a tag. Starting NFS server logging requires that you identify the tag for each file system. The global tag defines the default values. You can use the following parameters with each tag as needed.

defaultdir=path

Specifies the default directory path for the logging files. Unless you specify differently, the default directory is /var/nfs.

log=path/filename

Sets the path and file name for the log files. The default is /var/nfs/nfslog.

fhtable=path/filename

Selects the path and file name for the file-handle-to-path database files. The default is /var/nfs/fhtable.

buffer=path/filename

Determines the path and file name for the buffer files. The default is /var/nfs/nfslog_workbuffer.

logformat=basic|extended

Selects the format to be used when creating user-readable log files. The basic format produces a log file that is similar to some ftpd daemons. The extended format gives a more detailed view.

If the path is not specified, the path that is defined by defaultdir is used. Also, you can override defaultdir by using an absolute path.

To identify the files more easily, place the files in separate directories. Here is an example of the changes that are needed.

% cat /etc/nfs/nfslog.conf
#ident  "@(#)nfslog.conf        1.5     99/02/21 SMI"
#
  .
  .
# NFS server log configuration file.
#

global  defaultdir=/var/nfs \
        log=nfslog fhtable=fhtable buffer=nfslog_workbuffer

publicftp log=logs/nfslog fhtable=fh/fhtables buffer=buffers/workbuffer

In this example, any file system that is shared with log=publicftp would use the following values:

• The default directory would be /var/nfs.

• Log files would be stored in /var/nfs/logs/nfslog*.

• File-handle-to-path database tables would be stored in /var/nfs/fh/fhtables.

• Buffer files would be stored in /var/nfs/buffers/workbuffer.

For procedural information, refer to How to Enable NFS Server Logging.

NFS Daemons

To support NFS activities, several daemons are started when a system goes into run level 3 or multiuser mode. The mountd and nfsd daemons are run on systems that are servers. The automatic startup of the server daemons depends on the existence of entries that are labeled with the NFS file-system type in /etc/dfs/sharetab. To support NFS file locking, the lockd and statd daemons are run on NFS clients and servers.

This section describes the following daemons.

• automountd Daemon

• lockd Daemon

• mountd Daemon

• nfsd Daemon

• nfslogd Daemon

• statd Daemon

automountd Daemon

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

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

The command behaves in the following ways:

• -T enables tracing.

• -n disables browsing on all autofs node.

• -v selects to log all status messages to the console.

• -D name=value substitutes value for the automount map variable that is indicated by name.

lockd Daemon

This daemon supports record-locking operations on NFS files. The lockd daemon manages RPC connections between the client and the server for the Network Lock Manager (NLM) protocol. The daemon is normally started without any options. You can use three options with this command. See the lockd(1M) man page. These options can either be used from the command line or by editing the appropriate string in /etc/default/nfs. Changing /etc/default/nfs makes the change persist through system reboots. This feature is only available in the Solaris 9 release. The only way to make these changes permanent in other releases is to change /etc/init.d/nfs.client.

The LOCKD_GRACE_PERIOD=graceperiod parameter in /etc/default/nfs selects the number of seconds that the clients have to reclaim locks after a server reboot. During this time, the NFS server only processes reclaims of old locks. All other requests for service must wait until the grace period is over. This option affects the NFS server-side response, so this response can be changed only on an NFS server. The default value for graceperiod is 45 seconds. Reducing this value means that NFS clients can resume operation more quickly after a server reboot. However, a reduction increases the possibility that a client might not be able to recover all its locks. This same behavior can be used on the command line by starting the daemon with the -g graceperiod option.

The LOCKD_RETRANSMIT_TIMEOUT=timeout parameter in /etc/default/nfs selects the number of seconds to wait before retransmitting a lock request to the remote server. This option affects the NFS client-side service. The default value for timeout is 15 seconds. Decreasing the timeout value can improve response time for NFS clients on a noisy network. However, this change can cause additional server load by increasing the frequency of lock requests. The same parameter can be used from the command line by starting the daemon with the -t timeout option.

The LOCKD_SERVERS=nthreads parameter in /etc/default/nfs specifies the maximum number of concurrent threads that the server handles per connection. Base the value for nthreads on the load that is expected on the NFS server. The default value is 20. Each NFS client that uses TCP uses a single connection with the NFS server. Therefore, each client can use a maximum of 20 concurrent threads on the server. All NFS clients that use UDP share a single connection with the NFS server. Under these conditions, you might have to increase the number of threads that are available for the UDP connection. A minimum calculation would be to allow two threads for each UDP client. However, this number is specific to the workload on the client, so two threads per client might not be sufficient. The disadvantage to using more threads is that when the threads are used, more memory is used on the NFS server. If the threads are never used, however, increasing nthreads has no effect. The same parameter can be used from the command line by starting the daemon with the nthreads option.

mountd Daemon

This daemon handles file-system mount requests from remote systems and provides access control. The mountd daemon checks /etc/dfs/sharetab to determine which file systems are available for remote mounting and which systems are allowed to do the remote mounting. You can use the -v option and the -r option with this command. See the mountd(1M) man page.

The -v option runs the command in verbose mode. Every time an NFS server determines the access that a client should get, a message is printed on the console. The information that is generated can be useful when trying to determine why a client cannot access a file system.

The -r option rejects all future mount requests from clients. This option does not affect clients that already have a file system mounted.

nfsd Daemon

This daemon handles other client file-system requests. You can use several options with this command. See the nfsd(1M) man page for a complete listing. These options can either be used from the command line or by editing the appropriate string in /etc/default/nfs. Changing /etc/default/nfs makes the change persist through system reboots. This feature is only available in the Solaris 9 release. The only way to make these changes permanent in other releases is to change /etc/init.d/nfs.server.

The NFSD_LISTEN_BACKLOG=length parameter in /etc/default/nfs sets the length of the connection queue over connection-oriented transports for NFS and TCP. The default value is 32 entries. The same selection can be made from the command line by starting nfsd with the -l option.

The NFSD_MAX_CONNECTIONS=#_conn parameter in /etc/default/nfs selects the maximum number of connections per connection-oriented transport. The default value for #_conn is unlimited. The same parameter can be used from the command line by starting the daemon with the -c #_conn option.

The NFSD_SERVER=nservers parameter in /etc/default/nfs selects the maximum number of concurrent requests that a server can handle. The default value for nservers is 1, but the startup scripts select 16. The same selection can be made from the command line by starting nfsd with the nservers option.

Unlike older versions of this daemon, nfsd does not spawn multiple copies to handle concurrent requests. Checking the process table with ps only shows one copy of the daemon running.

nfslogd Daemon

This daemon provides operational logging. NFS operations that are logged against a server are based on the configuration options that are defined in /etc/default/nfslogd. When NFS server logging is enabled, records of all RPC operations on a selected file system are written to a buffer file by the kernel. Then nfslogd post-processes these requests. The name service switch is used to help map UIDs to logins and IP addresses to host names. The number is recorded if no match can be found through the identified name services.

Mapping of file handles to path names is also handled by nfslogd. The daemon tracks these mappings in a file-handle-to-path mapping table. One mapping table exists for each tag that is identified in /etc/nfs/nfslogd. After post-processing, the records are written to ASCII log files.

statd Daemon

This daemon works with lockd to provide crash and recovery functions for the lock manager. The statd daemon tracks the clients that hold locks on an NFS server. If a server crashes, on rebooting statd on the server contacts statd on the client. The client statd can then attempt to reclaim any locks on the server. The client statd also informs the server statd when a client has crashed so that the client's locks on the server can be cleared. You have no options to select with this daemon. For more information, see the statd(1M) man page.

In the Solaris 7 release, the way that statd tracks the clients has been improved. In all earlier Solaris releases, statd created files in /var/statmon/sm for each client by using the client's unqualified host name. This file naming caused problems if you had two clients in different domains that shared a host name, or if clients were not resident in the same domain as the NFS server. Because the unqualified host name only lists the host name, without any domain or IP-address information, the older version of statd had no way to differentiate between these types of clients. To fix this problem, the Solaris 7 statd creates a symbolic link in /var/statmon/sm to the unqualified host name by using the IP address of the client. The new link resembles the following:

# ls -l /var/statmon/sm
lrwxrwxrwx   1 daemon          11 Apr 29 16:32 ipv4.192.9.200.1 -> myhost
lrwxrwxrwx   1 daemon          11 Apr 29 16:32 ipv6.fec0::56:a00:20ff:feb9:2734 -> v6host
--w-------   1 daemon          11 Apr 29 16:32 myhost
--w-------   1 daemon          11 Apr 29 16:32 v6host

In this example, the client host name is myhost and the client's IP address is 192.9.200.1. If another host with the name myhost were mounting a file system, two symbolic links would lead to the host name.

NFS Commands

These commands must be run as root to be fully effective, but requests for information can be made by all users:

• automount Command

• clear_locks Command

• mount Command

• mountall Command

• setmnt Command

• share Command

• shareall Command

• showmount Command

• umount Command

• umountall Command

• unshare Command

• unshareall Command

automount Command

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

automount [ -t duration ] [ -v ]

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

If not specifically set, the value for duration is set to 5 minutes. In most circumstances, this value is good. However, on systems that have many automounted file systems, you might need to increase the duration value. In particular, if a server has many users active, checking the automounted file systems every 5 minutes can be inefficient. Checking the autofs file systems every 1800 seconds, which is 30 minutes, could be more optimal. By not unmounting the file systems every 5 minutes, /etc/mnttab can become large. To reduce the output when df checks each entry in /etc/mnttab, you can filter the output from df by using the -F option (see the df(1M) man page) or by using egrep.

You should consider the idea that adjusting the duration also changes how quickly changes to the automounter maps are reflected. Changes cannot be seen until the file system is unmounted. Refer to Modifying the Maps for instructions on how to modify automounter maps.

clear_locks Command

This command enables you to remove all file, record, and share locks for an NFS client. You must be root to run this command. From an NFS server, you can clear the locks for a specific client. From an NFS client, you can clear locks for that client on a specific server. The following example would clear the locks for the NFS client that is named tulip on the current system.

# clear_locks tulip

Using the -s option enables you to specify which NFS host to clear the locks from. You must run this option from the NFS client, which created the locks. In this situation, the locks from the client would be removed from the NFS server that is named bee.

# clear_locks -s bee

This command should only be run when a client crashes and cannot clear its locks. To avoid data corruption problems, do not clear locks for an active client.

mount Command

With this command, you can attach a named file system, either local or remote, to a specified mount point. For more information, see the mount(1M) man page. Used without arguments, mount displays a list of file systems that are currently mounted on your computer.

Many types of file systems are included in the standard Solaris installation. Each file-system type has a specific man page that lists the options to mount that are appropriate for that file-system type. The man page for NFS file systems is mount_nfs(1M). For UFS file systems, see mount_ufs(1M).

The Solaris 7 release includes the ability to select a path name to mount from an NFS server by using an NFS URL instead of the standard server:/pathname syntax. See How to Mount an NFS File System Using an NFS URL for further information.

The version of the mount command that is included in any Solaris release from 2.6 to the current release does not warn about invalid options. The command silently ignores any options that cannot be interpreted. Ensure that you verify all of the options that were used so that you can prevent unexpected behavior.

mount Options for NFS File Systems

The subsequent text lists some of the options that can follow the -o flag when you are mounting an NFS file system. For a complete list of options, refer to the mount_nfs(1M) man page.

bg|fg

These options can be used to select the retry behavior if a mount fails. The -bg option causes the mount attempts to be run in the background. The -fg option causes the mount attempt to be run in the foreground. The default is -fg, which is the best selection for file systems that must be available. This option prevents further processing until the mount is complete. -bg is a good selection for non-critical file systems, because the client can do other processing while waiting for the mount request to complete.

forcedirectio

This option improves performance of sequential reads on large files. Data is copied directly to a user buffer. No caching is done in the kernel on the client. This option is off by default. For an example of how to use this option, refer to Using the mount Command.

largefiles

With this option, you can access files that are larger than 2 Gbytes on a server that is running the Solaris 2.6 release. Whether a large file can be accessed can only be controlled on the server, so this option is silently ignored on NFS version 3 mounts. Starting with release 2.6, by default, all UFS file systems are mounted with largefiles. For mounts that use the NFS version 2 protocol, the largefiles option causes the mount to fail with an error.

nolargefiles

This option for UFS mounts guarantees that no large files can exist on the file system. See the mount_ufs(1M) man page. Because the existence of large files can only be controlled on the NFS server, no option for nolargefiles exists when using NFS mounts. Attempts to NFS-mount a file system by using this option are rejected with an error.

public

This option forces the use of the public file handle when contacting the NFS server. If the public file handle is supported by the server, the mounting operation is faster because the MOUNT protocol is not used. Also, because the MOUNT protocol is not used, the public option allows mounting to occur through a firewall.

rw|ro

The -rw and -ro options indicate whether a file system is to be mounted read-write or read-only. The default is read-write, which is the appropriate option for remote home directories, mail-spooling directories, or other file systems that need to be changed by users. The read-only option is appropriate for directories that should not be changed by users. For example, shared copies of the man pages should not be writable by users.

sec=mode

You can use this option to specify the authentication mechanism to be used during the mount transaction. The value for mode can be one of the values that is shown in Table 15–2. The modes are also defined in /etc/nfssec.conf.

Table 15–2 NFS Security Modes

Mode	Selected Authentication Service
krb5	Kerberos Version 5
krb5i	Kerberos Version 5 with integrity
krb5i	Kerberos Version 5 with privacy
none	No authentication
dh	Diffie-Hellman (DH) authentication
sys	Standard UNIX authentication

soft|hard

An NFS file system that is mounted with the soft option returns an error if the server does not respond. The hard option causes the mount to continue to retry until the server responds. The default is hard, which should be used for most file systems. Applications frequently do not check return values from soft-mounted file systems, which can make the application fail or can lead to corrupted files. If the application does check the return values, routing problems and other conditions can still confuse the application or lead to file corruption if the soft option is used. In most situations, the soft option should not be used. If a file system is mounted by using the hard option and becomes unavailable, an application that uses this file system hangs until the file system becomes available.

Using the mount Command

Refer to the following examples.

• In NFS version 2 or version 3, both of these commands mount an NFS file system from the server bee read-only:

  # mount -F nfs -r bee:/export/share/man /usr/man

  # mount -F nfs -o ro bee:/export/share/man /usr/man

• In NFS version 2 or version 3, this command uses the -O option to force the man pages from the server bee to be mounted on the local system even if /usr/man has already been mounted. See the following:

  # mount -F nfs -O bee:/export/share/man /usr/man

• In NFS version 2 or version 3, this command uses client failover:

  # mount -F nfs -r bee,wasp:/export/share/man /usr/man

  ---

  Note –

  When used from the command line, the listed servers must support the same version of the NFS protocol. Do not mix version 2 and version 3 servers when running mount from the command line. You can use mixed servers with autofs. Autofs automatically selects the best subset of version 2 or version 3 servers.

  ---

• Here is an example of using an NFS URL with the mount command in NFS version 2 or version 3:

  # mount -F nfs nfs://bee//export/share/man /usr/man

• Use the mount command with no arguments to display file systems that are mounted on a client.

  % mount / on /dev/dsk/c0t3d0s0 read/write/setuid on Tues Jan 24 13:20:47 1995 /usr on /dev/dsk/c0t3d0s6 read/write/setuid on Tues Jan 24 13:20:47 1995 /proc on /proc read/write/setuid on Tues Jan 24 13:20:47 1995 /dev/fd on fd read/write/setuid on Tues Jan 24 13:20:47 1995 /tmp on swap read/write on Tues Jan 24 13:20:51 1995 /opt on /dev/dsk/c0t3d0s5 setuid/read/write on Tues Jan 24 13:20:51 1995 /home/kathys on bee:/export/home/bee7/kathys intr/noquota/nosuid/remote on Tues Jan 24 13:22:13 1995

umount Command

This command enables you to remove a remote file system that is currently mounted. The umount command supports the -V option to allow for testing. You might also use the -a option to umount several file systems at one time. If mount_points are included with the -a option, those file systems are unmounted. If no mount points are included, an attempt is made to unmount all file systems that are listed in /etc/mnttab, except for the “required” file systems, such as /, /usr, /var, /proc, /dev/fd, and /tmp. Because the file system is already mounted and should have an entry in /etc/mnttab, you do not need to include a flag for the file-system type.

The -f option forces a busy file system to be unmounted. You can use this option to unhang a client that is hung while trying to mount an unmountable file system.

By forcing an unmount of a file system, you can cause data loss if files are being written to.

Using the umount Command

This example unmounts a file system that is mounted on /usr/man:

# umount /usr/man

This example displays the results of running umount -a -V:

# umount -a -V
umount /home/kathys
umount /opt
umount /home
umount /net

Notice that this command does not actually unmount the file systems.

mountall Command

Use this command to mount all file systems or a specific group of file systems that are listed in a file-system table. The command provides a way to do the following:

• Select the file-system type to be accessed with the -F FSType option

• Select all the remote file systems that are listed in a file-system table with the -r option

• Select all the local file systems with the -l option

Using the mountall Command

These two examples are equivalent:

# mountall -F nfs

# mountall -F nfs -r

umountall Command

Use this command to unmount a group of file systems. The -k option runs the fuser -k mount_point command to kill any processes that are associated with the mount_point. The -s option indicates that unmount is not to be performed in parallel. -l specifies that only local file systems are to be used, and -r specifies that only remote file systems are to be used. The -h host option indicates that all file systems from the named host should be unmounted. You cannot combine the -h option with -l or -r.

Using the umountall Command

This command unmounts all file systems that are mounted from remote hosts:

# umountall -r

This command unmounts all file systems that are currently mounted from the server bee:

# umountall -h bee

share Command

With this command, you can make a local file system on an NFS server available for mounting. You can also use the share command to display a list of the file systems on your system that are currently shared. The NFS server must be running in order for the share command to work. The NFS server software is started automatically during boot if an entry is in /etc/dfs/dfstab. The command does not report an error if the NFS server software is not running, so you yourself must verify that the software is running.

The objects that can be shared include any directory tree. However, each file system hierarchy is limited by the disk slice or partition that the file system is located on. For instance, sharing the root (/) file system would not also share /usr, unless these directories are on the same disk partition or slice. Normal installation places root on slice 0 and /usr on slice 6. Also, sharing /usr would not share any other local disk partitions that are mounted on subdirectories of /usr.

A file system cannot be shared if that file system is part of a larger file system that is already being shared. For example, if /usr and /usr/local are on one disk slice, /usr can be shared or /usr/local can be shared. However, if both directories need to be shared with different share options, /usr/local must to be moved to a separate disk slice.

You can gain access to a file system that is read-only shared through the file handle of a file system that is read-write shared. However, the two file systems have to be on the same disk slice. You can create a more secure situation. Place those file systems that need to be read-write on a separate partition or separate disk slice from the file systems that you need to share as read-only.

Non-File System-Specific share Options

Some of the options that you can include with the -o flag are as follows.

rw|ro

The pathname file system is shared read-write or read-only for all clients.

rw=accesslist

The file system is shared read-write for the clients that are listed only. All other requests are denied. Starting with the Solaris 2.6 release, the list of clients that are defined in accesslist has been expanded. See Setting Access Lists With the share Command for more information. You can use this option to override an -ro option.

NFS-Specific share Options

The options that you can use with NFS file systems include the following.

aclok

This option enables an NFS server that supports the NFS version 2 protocol to be configured to do access control for NFS version 2 clients. Without this option, all clients are given minimal access. With this option, the clients have maximal access. For instance, on file systems that are shared with the -aclok option, if anyone has read permissions, everyone does. However, without this option, you can deny access to a client who should have access permissions. A decision to permit too much access or too little access depends on the security systems already in place. See “Using Access Control Lists (ACLs)” in System Administration Guide: Security Services for more information about access control lists (ACLs).

---

Note –

To use ACLs, ensure that clients and servers run software that supports the NFS version 3 and NFS_ACL protocols. If the software only supports the NFS version 3 protocol, clients obtain correct access but cannot manipulate the ACLs. If the software supports the NFS_ACL protocol, the clients obtain correct access and can manipulate the ACLs. Starting with release 2.5, the Solaris system supports both protocols.

---

anon=uid

You use uid to select the user ID of unauthenticated users. If you set uid to -1, the server denies access to unauthenticated users. You can grant root access by setting anon=0, but this option allows unauthenticated users to have root access, so use the root option instead.

index=filename

When a user accesses an NFS URL, the -index=filename option forces the HTML file to load, instead of displaying a list of the directory. This option mimics the action of current browsers if an index.html file is found in the directory that the HTTP URL is accessing. This option is the equivalent of setting the DirectoryIndex option for httpd. For instance, suppose that the dfstab file entry resembles the following:

share -F nfs -o ro,public,index=index.html /export/web

These URLs then display the same information:

nfs://<server>/<dir> nfs://<server>/<dir>/index.html nfs://<server>//export/web/<dir> nfs://<server>//export/web/<dir>/index.html http://<server>/<dir> http://<server>/<dir>/index.html

log=tag

This option specifies the tag in /etc/nfs/nfslog.conf that contains the NFS server logging configuration information for a file system. This option must be selected to enable NFS server logging.

nosuid

This option signals that all attempts to enable the setuid or setgid mode should be ignored. NFS clients cannot create files with the setuid or setgid bits on.

public

The -public option has been added to the share command to enable WebNFS browsing. Only one file system on a server can be shared with this option.

root=accesslist

The server gives root access to the hosts in the list. By default, the server does not give root access to any remote hosts. If the selected security mode is anything other than -sec=sys, you can only include client host names in the accesslist. Starting with the Solaris 2.6 release, the list of clients that are defined in accesslist is expanded. See Setting Access Lists With the share Command for more information.

---

Caution –

Granting root access to other hosts has wide security implications. Use the -root= option with extreme caution.

---

sec=mode[:mode]

mode selects the security modes that are needed to obtain access to the file system. By default, the security mode is UNIX authentication. You can specify multiple modes, but use each security mode only once per command line. Each -mode option applies to any subsequent -rw, -ro, -rw=, -ro=, -root=, and -window= options until another -mode is encountered. The use of -sec=none maps all users to user nobody.

window=value

value selects the maximum lifetime in seconds of a credential on the NFS server. The default value is 30000 seconds or 8.3 hours.

Setting Access Lists With the share Command

In Solaris releases prior to 2.6, the accesslist that was included with either the -ro=, -rw=, or -root= option of the share command was restricted to a list of host names or netgroup names. Starting with the Solaris 2.6 release, the access list can also include a domain name, a subnet number, or an entry to deny access. These extensions should simplify file access control on a single server without having to change the namespace or maintain long lists of clients.

This command provides read-only access for most systems but allows read-write access for rose and lilac:

# share -F nfs -o ro,rw=rose:lilac /usr/src

In the next example, read-only access is assigned to any host in the eng netgroup. The client rose is specifically given read-write access.

# share -F nfs -o ro=eng,rw=rose /usr/src

You cannot specify both rw and ro without arguments. If no read-write option is specified, the default is read-write for all clients.

To share one file system with multiple clients, you must type all options on the same line. Multiple invocations of the share command on the same object “remember” only the last command that is run. This command enables read-write access to three client systems, but only rose and tulip are given access to the file system as root.

# share -F nfs -o rw=rose:lilac:tulip,root=rose:tulip /usr/src

When sharing a file system that uses multiple authentication mechanisms, ensure that you include the -ro, -ro=, -rw, -rw=, -root, and -window options after the correct security modes. In this example, UNIX authentication is selected for all hosts in the netgroup that is named eng. These hosts can only mount the file system in read-only mode. The hosts tulip and lilac can mount the file system read-write if these hosts use Diffie-Hellman authentication. With these options, tulip and lilac can mount the file system read-only even if these hosts are not using DH authentication. However, the host names must be listed in the eng netgroup.

# share -F nfs -o sec=dh,rw=tulip:lilac,sec=sys,ro=eng /usr/src

Even though UNIX authentication is the default security mode, UNIX authentication is not included if the -sec option is used. Therefore, you must include a -sec=sys option if UNIX authentication is to be used with any other authentication mechanism.

You can use a DNS domain name in the access list by preceding the actual domain name with a dot. The string that follows the dot is a domain name, not a fully qualified host name. The following entry allows mount access to all hosts in the eng.example.com domain:

# share -F nfs -o ro=.:.eng.example.com /export/share/man

In this example, the single “.” matches all hosts that are matched through the NIS or NIS+ namespaces. The results that are returned from these name services do not include the domain name. The “.eng.example.com” entry matches all hosts that use DNS for namespace resolution. DNS always returns a fully qualified host name. So, the longer entry is required if you use a combination of DNS and the other namespaces.

You can use a subnet number in an access list by preceding the actual network number or the network name with “@”. This character differentiates the network name from a netgroup or a fully qualified host name. You must identify the subnet in either /etc/networks or in an NIS or NIS+ namespace. The following entries have the same effect if the 129.144 subnet has been identified as the eng network:

# share -F nfs -o ro=@eng /export/share/man
# share -F nfs -o ro=@129.144 /export/share/man
# share -F nfs -o ro=@129.144.0.0 /export/share/man

The last two entries show that you do not need to include the full network address.

If the network prefix is not byte aligned, as with Classless Inter-Domain Routing (CIDR), the mask length can be explicitly specified on the command line. The mask length is defined by following either the network name or the network number with a slash and the number of significant bits in the prefix of the address. For example:

# share -f nfs -o ro=@eng/17 /export/share/man
# share -F nfs -o ro=@129.144.132/17 /export/share/man

In these examples, the “/17” indicates that the first 17 bits in the address are to be used as the mask. For additional information on CIDR, look up RFC 1519.

You can also select negative access by placing a “-” before the entry. Note that the entries are read from left to right. Therefore, you must place the negative access entries before the entry that the negative access entries apply to:

# share -F nfs -o ro=-rose:.eng.example.com /export/share/man

This example would allow access to any hosts in the eng.example.com domain except the host that is named rose.

unshare Command

This command allows you to make a previously available file system unavailable for mounting by clients. You can use the unshare command to unshare any file system—whether the file system was shared explicitly with the share command or automatically through /etc/dfs/dfstab. If you use the unshare command to unshare a file system that you shared through the dfstab file, be careful. Remember that the file system is shared again when you exit and reenter run level 3. You must remove the entry for this file system from the dfstab file if the change is to continue.

When you unshare an NFS file system, access from clients with existing mounts is inhibited. The file system might still be mounted on the client, but the files are not accessible.

Using the unshare Command

This command unshares a specific file system:

# unshare /usr/src

shareall Command

This command allows for multiple file systems to be shared. When used with no options, the command shares all entries in /etc/dfs/dfstab. You can include a file name to specify the name of a file that lists share command lines. If you do not include a file name, /etc/dfs/dfstab is checked. If you use a “-” to replace the file name, you can type share commands from standard input.

Using the shareall Command

This command shares all file systems that are listed in a local file:

# shareall /etc/dfs/special_dfstab

unshareall Command

This command makes all currently shared resources unavailable. The -F FSType option selects a list of file-system types that are defined in /etc/dfs/fstypes. This flag enables you to choose only certain types of file systems to be unshared. The default file system type is defined in /etc/dfs/fstypes. To choose specific file systems, use the unshare command.

Using the unshareall Command

This example should unshare all NFS-type file systems:

# unshareall -F nfs

showmount Command

This command displays one of the following:

• All clients that have remotely mounted file systems that are shared from an NFS server

• Only the file systems that are mounted by clients

• The shared file systems with the client access information

The command syntax is as follows:

showmount [ -ade ] [ hostname ]

-a

Prints a list of all the remote mounts. Each entry includes the client name and the directory.

-d

Prints a list of the directories that are remotely mounted by clients.

-e

Prints a list of the files that are shared or are exported.

hostname

Selects the NFS server to gather the information from.

If hostname is not specified the local host is queried.

Using the showmount Command

This command lists all clients and the local directories that the clients have mounted.

# showmount -a bee
lilac:/export/share/man
lilac:/usr/src
rose:/usr/src
tulip:/export/share/man

This command lists the directories that have been mounted.

# showmount -d bee
/export/share/man
/usr/src

This command lists file systems that have been shared.

# showmount -e bee
/usr/src								(everyone)
/export/share/man					eng

setmnt Command

This command creates an /etc/mnttab table. The mount and umount commands consult the table. Generally, you do not have to run this command manually, as this command runs automatically when a system is booted.

Other Useful Commands

These commands can be useful when troubleshooting NFS problems.

nfsstat Command

You can use this command to gather statistical information about NFS and RPC connections. The syntax of the command is as follows:

nfsstat [ -cmnrsz ]

-c

Displays client-side information

-m

Displays statistics for each NFS-mounted file system

-n

Specifies that NFS information is to be displayed on both the client side and the server side

-r

Displays RPC statistics

-s

Displays the server-side information

-z

Specifies that the statistics should be set to zero

If no options are supplied on the command line, the -cnrs options are used.

Gathering server-side statistics can be important for debugging problems when new software or new hardware is added to the computing environment. Running this command a minimum of once a week, and storing the numbers, provides a good history of previous performance.

Using the nfsstat Command

# nfsstat -s

Server rpc:
Connection oriented:
calls      badcalls   nullrecv   badlen      xdrcall    dupchecks  dupreqs
11420263   0          0          0           0          1428274    19
Connectionless:
calls      badcalls   nullrecv   badlen      xdrcall    dupchecks  dupreqs
14569706   0          0          0           0          953332     1601

Server nfs:
calls      badcalls
24234967   226
Version 2: (13073528 calls)
null       getattr    setattr    root        lookup     readlink   read
138612 1%  1192059 9% 45676 0%   0 0%        9300029 71% 9872 0%   1319897 10%
wrcache    write      create     remove      rename     link       symlink
0 0%       805444 6%  43417 0%   44951 0%    3831 0%    4758 0%    1490 0%
mkdir      rmdir      readdir    statfs
2235 0%    1518 0%    51897 0%   107842 0%
Version 3: (11114810 calls)
null       getattr    setattr    lookup      access     readlink   read
141059 1%  3911728 35% 181185 1% 3395029 30% 1097018 9% 4777 0%   960503 8%
write      create     mkdir      symlink     mknod      remove     rmdir
763996 6%  159257 1%  3997 0%    10532 0%    26 0%      164698 1%  2251 0%
rename     link       readdir    readdirplus fsstat     fsinfo     pathconf
53303 0%   9500 0%    62022 0%   79512 0%    3442 0%    34275 0%   3023 0%
commit    
73677 0%  

Server nfs_acl:
Version 2: (1579 calls)
null       getacl     setacl     getattr     access    
0 0%       3 0%       0 0%       1000 63%    576 36%   
Version 3: (45318 calls)
null       getacl     setacl    
0 0%       45318 100% 0 0%

The previous listing is an example of NFS server statistics. The first five lines relate to RPC and the remaining lines report NFS activities. In both sets of statistics, knowing the average number of badcalls or calls and the number of calls per week can help identify a problem. The badcalls value reports the number of bad messages from a client. This value can point out network hardware problems.

Some of the connections generate write activity on the disks. A sudden increase in these statistics could indicate trouble and should be investigated. For NFS version 2 statistics, the connections to note are setattr, write, create, remove, rename, link, symlink, mkdir, and rmdir. For NFS version 3 statistics, the value to watch is commit. If the commit level is high in one NFS server as compared to another almost identical server, check that the NFS clients have enough memory. The number of commit operations on the server grows when clients do not have available resources.

pstack Command

This command displays a stack trace for each process. The pstack command must be run by the owner of the process or by root. You can use pstack to determine where a process is hung. The only option that is allowed with this command is the PID of the process that you want to check. See the proc(1) man page.

The following example is checking the nfsd process that is running.

# /usr/proc/bin/pstack 243
243:    /usr/lib/nfs/nfsd -a 16
 ef675c04 poll     (24d50, 2, ffffffff)
 000115dc ???????? (24000, 132c4, 276d8, 1329c, 276d8, 0)
 00011390 main     (3, efffff14, 0, 0, ffffffff, 400) + 3c8
 00010fb0 _start   (0, 0, 0, 0, 0, 0) + 5c

The example shows that the process is waiting for a new connection request, which is a normal response. If the stack shows that the process is still in poll after a request is made, the process might be hung. Follow the instructions in How to Restart NFS Services to fix this problem. Review the instructions in NFS Troubleshooting Procedures to fully verify that your problem is a hung program.

rpcinfo Command

This command generates information about the RPC service that is running on a system. You can also use this command to change the RPC service. Many options are available with this command. See the rpcinfo(1M) man page. The following is a shortened synopsis for some of the options that you can use with the command:

rpcinfo [ -m | -s ] [ hostname ]

rpcinfo -T transport hostname [ progname ]

rpcinfo [ -t | -u ] [ hostname ] [ progname ]

-m

Displays a table of statistics of the rpcbind operations

-s

Displays a concise list of all registered RPC programs

-T

Displays information about services that use specific transports or protocols

-t

Probes the RPC programs that use TCP

-u

Probes the RPC programs that use UDP

transport

Selects the transport or protocol for the services

hostname

Selects the host name of the server you need information from

progname

Selects the RPC program to gather information about

If no value is given for hostname, the local host name is used. You can substitute the RPC program number for progname, but many users can remember the name and not the number. You can use the -p option in place of the -s option on those systems that do not run the NFS version 3 software.

The data that is generated by this command can include the following:

• The RPC program number

• The version number for a specific program

• The transport protocol that is being used

• The name of the RPC service

• The owner of the RPC service

Using the rpcinfo Command

This example gathers information on the RPC services that are running on a server. The text that is generated by the command is filtered by the sort command to make the output more readable. Several lines that list RPC services have been deleted from the example.

% rpcinfo -s bee |sort -n
   program version(s) netid(s)                         service     owner
    100000  2,3,4     udp6,tcp6,udp,tcp,ticlts,ticotsord,ticots rpcbind     superuser
    100001  4,3,2     ticlts,udp,udp6                  rstatd      superuser
    100002  3,2       ticots,ticotsord,tcp,tcp6,ticlts,udp,udp6 rusersd     superuser
    100003  3,2       tcp,udp,tcp6,udp6                nfs         superuser
    100005  3,2,1     ticots,ticotsord,tcp,tcp6,ticlts,udp,udp6 mountd      superuser
    100007  1,2,3     ticots,ticotsord,ticlts,tcp,udp,tcp6,udp6 ypbind      superuser
    100008  1         ticlts,udp,udp6                  walld       superuser
    100011  1         ticlts,udp,udp6                  rquotad     superuser
    100012  1         ticlts,udp,udp6                  sprayd      superuser
    100021  4,3,2,1   tcp,udp,tcp6,udp6                nlockmgr    superuser
    100024  1         ticots,ticotsord,ticlts,tcp,udp,tcp6,udp6 status      superuser
    100029  3,2,1     ticots,ticotsord,ticlts          keyserv     superuser
    100068  5         tcp,udp                          cmsd        superuser
    100083  1         tcp,tcp6                         ttdbserverd superuser
    100099  3         ticotsord                        autofs      superuser
    100133  1         ticots,ticotsord,ticlts,tcp,udp,tcp6,udp6 -           superuser
    100134  1         ticotsord                        tokenring   superuser
    100155  1         ticots,ticotsord,tcp,tcp6        smserverd   superuser
    100221  1         tcp,tcp6                         -           superuser
    100227  3,2       tcp,udp,tcp6,udp6                nfs_acl     superuser
    100229  1         tcp,tcp6                         metad       superuser
    100230  1         tcp,tcp6                         metamhd     superuser
    100231  1         ticots,ticotsord,ticlts          -           superuser
    100232  10        udp,udp6                         sadmind     superuser
    100234  1         ticotsord                        gssd        superuser
    100235  1         tcp,tcp6                         -           superuser
    100242  1         tcp,tcp6                         metamedd    superuser
    100249  1         ticots,ticotsord,ticlts,tcp,udp,tcp6,udp6 -           superuser
    300326  4         tcp,tcp6                         -           superuser
    300598  1         ticots,ticotsord,ticlts,tcp,udp,tcp6,udp6 -           superuser
    390113  1         tcp                              -           unknown
 805306368  1         ticots,ticotsord,ticlts,tcp,udp,tcp6,udp6 -           superuser
1289637086  1,5       tcp                              -           26069

This example shows how to gather information about a particular RPC service by selecting a particular transport on a server.

% rpcinfo -t bee mountd
program 100005 version 1 ready and waiting
program 100005 version 2 ready and waiting
program 100005 version 3 ready and waiting
% rpcinfo -u bee nfs
program 100003 version 2 ready and waiting
program 100003 version 3 ready and waiting

The first example checks the mountd service that is running over TCP. The second example checks the NFS service that is running over UDP.

snoop Command

This command is often used to watch for packets on the network. The snoop command must be run as root. The use of this command is a good way to ensure that the network hardware is functioning on both the client and the server. Many options are available. See the snoop(1M) man page. A shortened synopsis of the command follows:

snoop [ -d device ] [ -o filename ] [ host hostname ]

-d device

Specifies the local network interface

-o filename

Stores all the captured packets into the named file

hostname

Displays packets going to and from a specific host only

The -d device option is useful on those servers that have multiple network interfaces. You can use many other expressions besides setting the host. A combination of command expressions with grep can often generate data that is specific enough to be useful.

When troubleshooting, make sure that packets are going to and from the proper host. Also, look for error messages. Saving the packets to a file can simplify the review of the data.

truss Command

You can use this command to see if a process is hung. The truss command must be run by the owner of the process or by root. You can use many options with this command. See the truss(1) man page. A shortened syntax of the command follows:

truss [ -t syscall ] -p pid

-t syscall

Selects system calls to trace

-p pid

Indicates the PID of the process to be traced

The syscall can be a comma-separated list of system calls to be traced. Also, starting syscall with an ! selects to exclude the listed system calls from the trace.

This example shows that the process is waiting for another connection request from a new client.

# /usr/bin/truss -p 243
poll(0x00024D50, 2, -1)         (sleeping...)

The previous example shows a normal response. If the response does not change after a new connection request has been made, the process could be hung. Follow the instructions in How to Restart NFS Services to fix the hung program. Review the instructions in NFS Troubleshooting Procedures to fully verify that your problem is a hung program.

How the NFS Service Works

The following sections describe some of the complex functions of the NFS software.

• Version 2 and Version 3 Negotiation

• UDP and TCP Negotiation

• File Transfer Size Negotiation

• How File Systems Are Mounted

• Effects of the -public Option and NFS URLs When Mounting

• Client-Side Failover

• Large Files

• How NFS Server Logging Works

• How the WebNFS Service Works

• WebNFS Limitations With Web Browser Use

• Secure NFS System

• Secure RPC

Version 2 and Version 3 Negotiation

NFS servers might be supporting clients that are not using the NFS version 3 software. So, part of the initiation procedure includes negotiation of the protocol level. If both the client and the server can support version 3, that version is used. If either the client or the server can only support version 2, that version is selected.

You can override the values that are determined by the negotiation by using the -vers option with the mount command. See the mount_nfs(1M) man page. Under most circumstances, you should not have to specify the version level, as the best level is selected by default.

UDP and TCP Negotiation

During initiation, the transport protocol is also negotiated. By default, the first connection-oriented transport that is supported on both the client and the server is selected. If this selection does not succeed, the first available connectionless transport protocol is used. The transport protocols that are supported on a system are listed in /etc/netconfig. TCP is the connection-oriented transport protocol that is supported by the release. UDP is the connectionless transport protocol.

When both the NFS protocol version and the transport protocol are determined by negotiation, the NFS protocol version is given precedence over the transport protocol. The NFS version 3 protocol that uses UDP is given higher precedence than the NFS version 2 protocol that is using TCP. You can manually select both the NFS protocol version and the transport protocol with the mount command. See the mount_nfs(1M) man page. Under most conditions, allow the negotiation to select the best options.

File Transfer Size Negotiation

The file transfer size establishes the size of the buffers that are used when transferring data between the client and the server. In general, larger transfer sizes are better. The NFS version 3 protocol has an unlimited transfer size. However, starting with the Solaris 2.6 release, the software bids a default buffer size of 32 Kbytes. The client can bid a smaller transfer size at mount time if needed, but under most conditions this bid is not necessary.

The transfer size is not negotiated with systems that use the NFS version 2 protocol. Under this condition, the maximum transfer size is set to 8 Kbytes.

You can use the -rsize and -wsize options to set the transfer size manually with the mount command. You might need to reduce the transfer size for some PC clients. Also, you can increase the transfer size if the NFS server is configured to use larger transfer sizes.

How File Systems Are Mounted

When a client needs to mount a file system from a server, the client must obtain a file handle from the server. The file handle must correspond to the file system. This process requires that several transactions occur between the client and the server. In this example, the client is attempting to mount /home/terry from the server. A snoop trace for this transaction follows.

client -> server PORTMAP C GETPORT prog=100005 (MOUNT) vers=3 proto=UDP
server -> client PORTMAP R GETPORT port=33492
client -> server MOUNT3 C Null
server -> client MOUNT3 R Null 
client -> server MOUNT3 C Mount /export/home9/terry
server -> client MOUNT3 R Mount OK FH=9000 Auth=unix
client -> server PORTMAP C GETPORT prog=100003 (NFS) vers=3 proto=TCP
server -> client PORTMAP R GETPORT port=2049
client -> server NFS C NULL3
server -> client NFS R NULL3 
client -> server NFS C FSINFO3 FH=9000
server -> client NFS R FSINFO3 OK
client -> server NFS C GETATTR3 FH=9000
server -> client NFS R GETATTR3 OK

In this trace, the client first requests the mount port number from the portmap service on the NFS server. After the client receives the mount port number (33492), that number is used to ping the service on the server. After the client has determined that a service is running on that port number, the client then makes a mount request. When the server responds to this request, the server includes the file handle for the file system (9000) being mounted. The client then sends a request for the NFS port number. When the client receives the number from the server, the client pings the NFS service (nfsd). Also, the client requests NFS information about the file system that uses the file handle.

In the following trace, the client is mounting the file system with the public option.

client -> server NFS C LOOKUP3 FH=0000 /export/home9/terry
server -> client NFS R LOOKUP3 OK FH=9000
client -> server NFS C FSINFO3 FH=9000
server -> client NFS R FSINFO3 OK
client -> server NFS C GETATTR3 FH=9000
server -> client NFS R GETATTR3 OK

By using the default public file handle (which is 0000), all of the transactions to obtain information from the portmap service and to determine the NFS port number are skipped.

Effects of the -public Option and NFS URLs When Mounting

Using the -public option can create conditions that cause a mount to fail. Adding an NFS URL can also confuse the situation. The following list describes the specifics of how a file system is mounted when you use these options.

Public option with NFS URL – Forces the use of the public file handle. The mount fails if the public file handle is not supported.




Public option with regular path – Forces the use of the public file handle. The mount fails if the public file handle is not supported.




NFS URL only – Use the public file handle if this file handle is enabled on the NFS server. If the mount fails when using the public file handle, then try the mount with the MOUNT protocol.




Regular path only – Do not use the public file handle. The MOUNT protocol is used.

Client-Side Failover

By using client-side failover, an NFS client can know about multiple servers that are making the same data available and can switch to an alternate server when the current server is unavailable. The file system can become unavailable under one of the following circumstances.

• If the server that the file system is connected to crashes

• If the server is overloaded

• If a network fault occurs

The failover, under these conditions, is normally transparent to the user. Thus, the failover can occur at any time without disrupting the processes that are running on the client.

Failover requires that the file system be mounted read-only. The file systems must be identical for the failover to occur successfully. See What Is a Replicated File System? for a description of what makes a file system identical. A static file system or a file system that is not changed often is the best candidate for failover.

You cannot use CacheFS and client-side failover on the same NFS mount. Extra information is stored for each CacheFS file system. This information cannot be updated during failover, so only one of these two features can be used when mounting a file system.

The number of replicas that need to be established for every file system depends on many factors. Ideally, you should have a minimum of two servers. Each server should support multiple subnets. This setup is better than having a unique server on each subnet. The process requires that each listed server be checked. Therefore, if more servers are listed, each mount is slower.

Failover Terminology

To fully comprehend the process, you need to understand two terms.

• failover – The process of selecting a server from a list of servers that support a replicated file system. Normally, the next server in the sorted list is used, unless it fails to respond.

• remap – To make use of a new server. Through normal use, the clients store the path name for each active file on the remote file system. During the remap, these path names are evaluated to locate the files on the new server.

What Is a Replicated File System?

For the purposes of failover, a file system can be called a replica when each file is the same size and has the same vnode type as the original file system. Permissions, creation dates, and other file attributes are not considered. If the file size or vnode types are different, the remap fails and the process hangs until the old server becomes available.

You can maintain a replicated file system by using rdist, cpio, or another file transfer mechanism. Because updating the replicated file systems causes inconsistency, follow these suggestions for best results:

• Rename the old version of the file before installing a new version of the file.

• Run the updates at night when client usage is low.

• Keep the updates small.

• Minimize the number of copies.

Failover and NFS Locking

Some software packages require read locks on files. To prevent these products from breaking, read locks on read-only file systems are allowed but are visible to the client side only. The locks persist through a remap because the server does not “know” about the locks. Because the files should not change, you do not need to lock the file on the server side.

Large Files

Starting with 2.6, the Solaris release supports files that are over 2 Gbytes. By default, UFS file systems are mounted with the -largefiles option to support the new capability. Previous releases cannot handle files of this size. See How to Disable Large Files on an NFS Server for instructions.

If the server's file system is mounted with the -largefiles option, a Solaris 2.6 NFS client can access large files without the need for changes. However, not all 2.6 commands can handle these large files. See largefile(5) for a list of the commands that can handle the large files. Clients that cannot support the NFS version 3 protocol with the large file extensions cannot access any large files. Although clients that run the Solaris 2.5 release can use the NFS version 3 protocol, large file support was not included in that release.

How NFS Server Logging Works

NFS server logging provides records of NFS reads and writes, as well as operations that modify the file system. This data can be used to track access to information. In addition, the records can provide a quantitative way to measure interest in the information.

When a file system with logging enabled is accessed, the kernel writes raw data into a buffer file. This data includes the following:

• A timestamp

• The client IP address

• The UID of the requester

• The file handle of the file or directory object that is being accessed

• The type of operation that occurred

The nfslogd daemon converts this raw data into ASCII records that are stored in log files. During the conversion, the IP addresses are modified to host names and the UIDs are modified to logins if the name service that is enabled can find matches. The file handles are also converted into path names. To accomplish the conversion, the daemon tracks the file handles and stores information in a separate file handle-to-path table. That way, the path does not have to be re-identified each time a file handle is accessed. Because no changes to the mappings are made in the file handle-to-path table if nfslogd is turned off, you must keep the daemon running.

How the WebNFS Service Works

The WebNFS service makes files in a directory available to clients by using a public file handle. A file handle is an address that is generated by the kernel that identifies a file for NFS clients. The public file handle has a predefined value, so the server does not need to generate a file handle for the client. The ability to use this predefined file handle reduces network traffic by eliminating the MOUNT protocol. This ability should also accelerate processes for the clients.

By default, the public file handle on an NFS server is established on the root file system. This default provides WebNFS access to any clients that already have mount privileges on the server. You can change the public file handle to point to any file system by using the share command.

When the client has the file handle for the file system, a LOOKUP is run to determine the file handle for the file to be accessed. The NFS protocol allows the evaluation of only one path name component at a time. Each additional level of directory hierarchy requires another LOOKUP. A WebNFS server can evaluate an entire path name with a single multicomponent lookup transaction when the LOOKUP is relative to the public file handle. Multicomponent lookup enables the WebNFS server to deliver the file handle to the desired file without exchanging the file handles for each directory level in the path name.

In addition, an NFS client can initiate concurrent downloads over a single TCP connection. This connection provides quick access without the additional load on the server that is caused by setting up multiple connections. Although web browser applications support concurrent downloading of multiple files, each file has its own connection. By using one connection, the WebNFS software reduces the overhead on the server.

If the final component in the path name is a symbolic link to another file system, the client can access the file if the client already has access through normal NFS activities.

Normally, an NFS URL is evaluated relative to the public file handle. The evaluation can be changed to be relative to the server's root file system by adding an additional slash to the beginning of the path. In this example, these two NFS URLs are equivalent if the public file handle has been established on the /export/ftp file system.

nfs://server/junk
nfs://server//export/ftp/junk

How WebNFS Security Negotiation Works

The Solaris 8 release includes a new protocol so a WebNFS client can negotiate a selected security mechanism with a WebNFS server. The new protocol uses security negotiation multicomponent lookup, which is an extension to the multicomponent lookup that was used in earlier versions of the WebNFS protocol.

The WebNFS client initiates the process by making a regular multicomponent lookup request by using the public file handle. Because the client has no knowledge of how the path is protected by the server, the default security mechanism is used. If the default security mechanism is not sufficient, the server replies with an AUTH_TOOWEAK error. This reply indicates that the default mechanism is not valid. The client needs to use a stronger default mechanism.

When the client receives the AUTH_TOOWEAK error, the client sends a request to the server to determine which security mechanisms are required. If the request succeeds, the server responds with an array of security mechanisms that are required for the specified path. Depending on the size of the array of security mechanisms, the client might have to make more requests to obtain the complete array. If the server does not support WebNFS security negotiation, the request fails.

After a successful request, the WebNFS client selects the first security mechanism from the array that the client supports. The client then issues a regular multicomponent lookup request by using the selected security mechanism to acquire the file handle. All subsequent NFS requests are made by using the selected security mechanism and the file handle.

WebNFS Limitations With Web Browser Use

Several functions that a web site that uses HTTP can provide are not supported by the WebNFS software. These differences stem from the fact that the NFS server only sends the file, so any special processing must be done on the client. If you need to have one web site configured for both WebNFS and HTTP access, consider the following issues:

• NFS browsing does not run CGI scripts. So, a file system with an active web site that uses many CGI scripts might not be appropriate for NFS browsing.

• The browser might start different viewers in order to handle files in different file formats. Accessing these files through an NFS URL starts an external viewer if the file type can be determined by the file name. The browser should recognize any file name extension for a standard MIME type when an NFS URL is used. As an explanation, the WebNFS software does not check inside the file to determine the file type. So, the only way to determine a file type is by the file name extension.

• NFS browsing cannot utilize server-side image maps (clickable images). However, NFS browsing can utilize client-side image maps (clickable images) because the URLs are defined with the location. No additional response is required from the document server.

Secure NFS System

The NFS environment is a powerful way and convenient way to share file systems on a network of different computer architectures and operating systems. However, the same features that make sharing file systems through NFS operation convenient also pose some security problems. Historically, most NFS implementations have used UNIX (or AUTH_SYS) authentication, but stronger authentication methods such as AUTH_DH have also been available. When using UNIX authentication, an NFS server authenticates a file request by authenticating the computer that makes the request, but not the user. Therefore, a client user can run su and impersonate the owner of a file. If DH authentication is used, the NFS server authenticates the user, making this sort of impersonation much harder.

With root access and knowledge of network programming, anyone can introduce arbitrary data into the network and extract any data from the network. The most dangerous attacks are those attacks that involve the introduction of data. An example is the impersonation of a user by generating the right packets or by recording “conversations” and replaying them later. These attacks affect data integrity. Attacks that involve passive eavesdropping—merely listening to network traffic without impersonating anybody—are not as dangerous, as data integrity is not compromised. Users can protect the privacy of sensitive information by encrypting data that is sent over the network.

A common approach to network security problems is to leave the solution to each application. A better approach is to implement a standard authentication system at a level that covers all applications.

The Solaris operating environment includes an authentication system at the level of remote procedure call (RPC)—the mechanism on which NFS operation is built. This system, known as Secure RPC, greatly improves the security of network environments and provides additional security to services such as the NFS system. When the NFS system uses the facilities that are provided by Secure RPC, it is known as a Secure NFS system.

Secure RPC

Secure RPC is fundamental to the Secure NFS system. The goal of Secure RPC is to build a system that is at minimum as secure as a time-sharing system. In a time-sharing system all users share a single computer. A time-sharing system authenticates a user through a login password. With data encryption standard (DES) authentication, the same authentication process is completed. Users can log in on any remote computer just as users can log in on a local terminal. The users' login passwords are their passports to network security. In a time-sharing environment, the system administrator has an ethical obligation not to change a password to impersonate someone. In Secure RPC, the network administrator is trusted not to alter entries in a database that stores public keys.

You need to be familiar with two terms to understand an RPC authentication system: credentials and verifiers. Using ID badges as an example, the credential is what identifies a person: a name, address, birthday, and so on. The verifier is the photo that is attached to the badge. You can be sure the badge has not been stolen by checking the photo on the badge against the person who is carrying the badge. In RPC, the client process sends both a credential and a verifier to the server with each RPC request. The server sends back only a verifier because the client already “knows” the server's credentials.

RPC's authentication is open ended, which means that a variety of authentication systems can be plugged into it, such as UNIX, DH, and KERB.

When UNIX authentication is used by a network service, the credentials contain the client's host name, UID, GID, and group-access list. However, the verifier contains nothing. Because no verifier exists, a superuser could falsify appropriate credentials by using commands such as su. Another problem with UNIX authentication is that UNIX authentication assumes all computers on a network are UNIX computers. UNIX authentication breaks down when applied to other operating systems in a heterogeneous network.

To overcome the problems of UNIX authentication, Secure RPC uses DH authentication.

DH Authentication

DH authentication uses the Data Encryption Standard (DES) and Diffie-Hellman public-key cryptography to authenticate both users and computers in the network. DES is a standard encryption mechanism. Diffie-Hellman public-key cryptography is a cipher system that involves two keys: one public and one secret. The public keys and secret keys are stored in the namespace. NIS stores the keys in the public-key map. These maps contain the public key and secret key for all potential users. See the System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP) for more information on how to set up the maps.

The security of DH authentication is based on a sender's ability to encrypt the current time, which the receiver can then decrypt and check against its own clock. The timestamp is encrypted with DES. The requirements for this scheme to work are as follows:

• The two agents must agree on the current time.

• The sender and receiver must be using the same encryption key.

If a network runs a time-synchronization program, the time on the client and the server is synchronized automatically. If a time-synchronization program is not available, timestamps can be computed by using the server's time instead of the network time. The client asks the server for the time before starting the RPC session, then computes the time difference between its own clock and the server's. This difference is used to offset the client's clock when computing timestamps. If the client and server clocks get out of synchronization to the point where the server begins to reject the client's requests, the DH authentication system on the client resynchronizes with the server.

The client and server arrive at the same encryption key by generating a random conversation key, also known as the session key, and by using public-key cryptography to deduce a common key. The common key is a key that only the client and server are capable of deducing. The conversation key is used to encrypt and decrypt the client's timestamp. The common key is used to encrypt and decrypt the conversation key.

KERB Authentication

Kerberos is an authentication system that was developed at MIT. Encryption in Kerberos is based on DES. Kerberos support is no longer supplied as part of Secure RPC, but a server-side and client-side implementation is included with the Solaris 9 release. See “Introduction to SEAM” in System Administration Guide: Security Services for more information about the Solaris 9 implementation of Kerberos Authentication.

Using Secure RPC With NFS

Be aware of the following points if you plan to use Secure RPC:

• If a server crashes when no one is around (after a power failure, for example), all the secret keys that are stored on the system are deleted. Now no process can access secure network services or mount an NFS file system. The important processes during a reboot are usually run as root. Therefore, these processes would work if root's secret key were stored away, but nobody is available to type the password that decrypts it. keylogin -r allows root to store the clear secret key in /etc/.rootkey, which keyserv reads.

• Some systems boot in single-user mode, with a root login shell on the console and no password prompt. Physical security is imperative in such cases.

• Diskless computer booting is not totally secure. Somebody could impersonate the boot server and boot a devious kernel that, for example, makes a record of your secret key on a remote computer. The Secure NFS system provides protection only after the kernel and the key server are running. Otherwise, no way exists to authenticate the replies that are given by the boot server. This limitation could be a serious problem, but the limitation requires a sophisticated attack, using kernel source code. Also, the crime would leave evidence. If you polled the network for boot servers, you would discover the devious boot server's location.

• Most setuid programs are owned by root. If the secret key for root is stored in /etc/.rootkey, these programs behave as they always have. If a setuid program is owned by a user, however, the setuid program might not always work. For example, suppose that a setuid program is owned by dave and dave has not logged into the computer since it booted. The program would not be able to access secure network services.

• If you log in to a remote computer (using login, rlogin, or telnet) and use keylogin to gain access, you give access to your account. The reason is that your secret key is passed to that computer's key server, which then stores your secret key. This process is only a concern if you do not trust the remote computer. If you have doubts, however, do not log in to a remote computer if the remote computer requires a password. Instead, use the NFS environment to mount file systems that are shared by the remote computer. As an alternative, you can use keylogout to delete the secret key from the key server.

• If a home directory is shared with the -o sec=dh option, remote logins can be a problem. If the /etc/hosts.equiv or ~/.rhosts files are not set to prompt for a password, the login succeeds. However, the users cannot access their home directories because no authentication has occurred locally. If the user is prompted for a password, the user has access to his or her home directory if the password matches the network password.

Autofs Maps

Autofs uses three types of maps:

• Master map

• Direct maps

• Indirect maps

Master Autofs Map

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

Example 15–1 Sample /etc/auto_master File

# Master map for automounter 
# 
+auto_master 
/net            -hosts           -nosuid,nobrowse 
/home           auto_home        -nobrowse 
/-              auto_direct     -ro  

This example shows the generic auto_master file with one addition for the auto_direct map. Each line in the master map /etc/auto_master has the following syntax:

mount-point map-name [ mount-options ]

mount-point

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

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

map-name

map-name is the map autofs uses to find directions to locations, or mount information. If the name is preceded by a slash (/), autofs interprets the name as a local file. Otherwise, autofs searches for the mount information by using the search that is specified in the name-service switch configuration file (/etc/nsswitch.conf). Special maps are also used for /net. See Mount Point /net for more information.

mount-options

mount-options is an optional, comma-separated list of options that apply to the mounting of the entries that are specified in map-name, unless the entries in map-name list other options. Options for each specific type of file system are listed in the mount man page for that file system. For example, see the mount_nfs(1M) man page for NFS-specific mount options. For NFS-specific mount points, the bg (background) and fg (foreground) options do not apply.

A line that begins with # is a comment. All the text that follows until the end of the line is ignored.

To split long lines into shorter ones, put a backslash (\) at the end of the line. The maximum number of characters of an entry is 1024.

If the same mount point is used in two entries, the first entry is used by the automount command. The second entry is ignored.

Mount Point /home

The mount point /home is the directory under which the entries that are listed in /etc/auto_home (an indirect map) are to be mounted.

Autofs runs on all computers and supports /net and /home (automounted home directories) by default. These defaults can be overridden by entries in the NIS auto.master map or NIS+ auto_master table, or by local editing of the /etc/auto_master file.

Mount Point /net

Autofs mounts under the directory /net all the entries in the special map -hosts. The map is a built-in map that uses only the hosts database. Suppose that the computer gumbo is in the hosts database and it exports any of its file systems. The following command changes the current directory to the root directory of the computer gumbo.

% cd /net/gumbo

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

With the /net method of access, the server name is in the path and is location dependent. If you want to move an exported file system from one server to another, the path might no longer work. Instead, you should set up an entry in a map specifically for the file system you want rather than use /net.

Autofs checks the server's export list only at mount time. After a server's file systems are mounted, autofs does not check with the server again until the server's file systems are automatically unmounted. Therefore, newly exported file systems are not “seen” until the file systems on the client are unmounted and then remounted.

Direct Autofs Maps

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

/usr/local          -ro \
   /bin                   ivy:/export/local/sun4 \
   /share                 ivy:/export/local/share \
   /src                   ivy:/export/local/src
/usr/man            -ro   oak:/usr/man \
                          rose:/usr/man \
                          willow:/usr/man 
/usr/games          -ro   peach:/usr/games 
/usr/spool/news     -ro   pine:/usr/spool/news \
                          willow:/var/spool/news 

Lines in direct maps have the following syntax:

key [ mount-options ] location

key

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

mount-options

mount-options is the options that you want to apply to this particular mount. These options are required only if the options differ from the map default. Options for each specific type of file system are listed in the mount man page for that file system. For example, see the mount_cachefs(1M) man page for CacheFS specific mount options.

location

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

---

Note –

The pathname should not include an automounted mount point. The pathname should be the actual absolute path to the file system. For instance, the location of a home directory should be listed as server:/export/home/username, not as server:/home/username.

---

As in the master map, a line that begins with # is a comment. All the text that follows until the end of the line is ignored. Put a backslash at the end of the line to split long lines into shorter ones.

Of all the maps, the entries in a direct map most closely resemble the corresponding entries in /etc/vfstab. An entry might appear in /etc/vfstab as follows:

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

The equivalent entry appears in a direct map as follows:

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

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

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

Mount Point /-

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

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

Indirect Autofs 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, such as home directories. The auto_home map is an example of an indirect map.

Lines in indirect maps have the following general syntax:

key [ mount-options ] location

key

key is a simple name without slashes in an indirect map.

mount-options

mount-options is the options that you want to apply to this particular mount. These options are required only if the options differ from the map default. Options for each specific type of file system are listed in the mount man page for that file system. For example, see the mount_nfs(1M) man page for NFS-specific mount options.

location

location is the location of the file system. One or more file systems are specified as server:pathname.

---

Note –

The pathname should not include an automounted mount point. The pathname should be the actual absolute path to the file system. For instance, the location of a directory should be listed as server:/usr/local, not as server:/net/server/usr/local.

---

As in the master map, a line that begins with # is a comment. All the text that follows until the end of the line is ignored. Put a backslash (\) at the end of the line to split long lines into shorter ones. Example 15–1 shows an auto_master map that contains the following entry:

/home      auto_home        -nobrowse    

auto_home is the name of the indirect map that contains the entries to be mounted under /home. A typical auto_home map might contain the following:

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

As an example, assume that the previous map is on host oak. Suppose that the user linda has an entry in the password database that specifies her home directory as /home/linda. Whenever linda logs in to computer oak, autofs mounts the directory /export/home/linda that resides on the computer peach. Her home directory is mounted read-write, nosuid.

Assume the following conditions occur: User linda's home directory is listed in the password database as /home/linda. Anybody, including Linda, has access to this path from any computer that is 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).

No concatenation of options occurs between the automounter maps. Any options that are added to an automounter map override all options that are listed in maps that are searched earlier. For instance, options that are included in the auto_master map are overridden by corresponding entries in any other map.

On a network without a name service, you have to change all the relevant files (such as /etc/passwd) on all systems on the network to allow Linda access to her files. With NIS, make the changes on the NIS master server and propagate the relevant databases to the slave servers. On a network that is running NIS+, propagating the relevant databases to the slave servers is done automatically after the changes are made.

How Autofs Works

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

The components that work together to accomplish automatic mounting are the following:

• The automount command

• The autofs file system

• The automountd daemon

The automount command, which is called at system startup time, reads the master map file auto_master to create the initial set of autofs mounts. These autofs mounts are not automatically mounted at startup time. These mounts are points under which file systems are mounted in the future. These points are also known as trigger nodes.

After the autofs mounts are set up, these mounts can trigger file systems to be mounted under them. For example, when autofs receives a request to access a file system that is not currently mounted, autofs calls automountd, which actually mounts the requested file system.

After initially mounting autofs mounts, the automount command is used to update autofs mounts as necessary. The command compares the list of mounts in the auto_master map with the list of mounted file systems in the mount table file /etc/mnttab (formerly /etc/mtab). automount then makes the appropriate changes. This process allows system administrators to change mount information within auto_master and have those changes used by the autofs processes without having to stop and restart the autofs daemon. After the file system is mounted, further access does not require any action from automountd until the file system is automatically unmounted.

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

The following is a simplified overview of how autofs works.

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

Figure 15–1 /etc/init.d/autofs Script Starts automount

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

When a request is made to access a file system at an autofs mount point, the following occurs:

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, creates the trigger nodes, and performs the mount.

4. Autofs allows the intercepted request to proceed.

5. Autofs unmounts the file system after a period of inactivity.

Mounts that are managed through the autofs service should not be manually mounted or unmounted. Even if the operation is successful, the autofs service does not check that the object has been unmounted, resulting in possible inconsistencies. A reboot clears all of the autofs mount points.

How Autofs Navigates Through the Network (Maps)

Autofs searches a series of maps to navigate 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. Effectively, the maps contain network-wide equivalents of UNIX administration files. Maps are available locally or through a network name service such as NIS or NIS+. You create maps to meet the needs of your environment by using the Solaris Management Console tools. See Modifying How Autofs Navigates the Network (Modifying Maps).

How Autofs Starts the Navigation Process (Master Map)

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

Figure 15–2 Navigation Through the Master Map

Autofs Mount Process

What the autofs service does when a mount request is triggered depends on how the automounter maps are configured. The mount process is generally the same for all mounts. However, the final result changes with the mount point that is specified and the complexity of the maps. Starting with the Solaris 2.6 release, the mount process has also been changed to include the creation of the trigger nodes.

Simple Autofs Mount

To help explain the autofs mount process, assume that the following files are installed.

$ cat /etc/auto_master
# Master map for automounter
#
+auto_master
/net        -hosts        -nosuid,nobrowse
/home       auto_home     -nobrowse
/share      auto_share
$ cat /etc/auto_share
# share directory map for automounter
#
ws          gumbo:/export/share/ws

When the /share directory is accessed, the autofs service creates a trigger node for /share/ws, which can be seen in /etc/mnttab as an entry that resembles the following entry:

-hosts  /share/ws     autofs  nosuid,nobrowse,ignore,nest,dev=###

When the /share/ws directory is accessed, the autofs service completes the process with these steps:

1. Pings the server's mount service to see if the service is alive.

2. Mounts the requested file system under /share. Now, the /etc/mnttab file contains the following entries:

   -hosts /share/ws autofs nosuid,nobrowse,ignore,nest,dev=### gumbo:/export/share/ws /share/ws nfs nosuid,dev=#### #####

Hierarchical Mounting

When multiple layers are defined in the automounter files, the mount process becomes more complex. Suppose that you expand the /etc/auto_shared file from the previous example to contain the following:

# share directory map for automounter
#
ws       /       gumbo:/export/share/ws
         /usr    gumbo:/export/share/ws/usr

The mount process is basically the same as the previous example when the /share/ws mount point is accessed. In addition, a trigger node to the next level (/usr) is created in the /share/ws file system so that the next level can be mounted if it is accessed. In this example, /export/share/ws/usr must exist on the NFS server in order for the trigger node to be created.

Do not use the -soft option when specifying hierarchical layers. Refer to Autofs Unmounting for an explanation of this limitation.

Autofs Unmounting

The unmounting that occurs after a certain amount of idle time is from the bottom up (reverse order of mounting). If one of the directories at a higher level in the hierarchy is busy, only file systems below that directory are unmounted. During the unmounting process, any trigger nodes are removed and then the file system is unmounted. If the file system is busy, the unmount fails and the trigger nodes are reinstalled.

Do not use the -soft option when specifying hierarchical layers. If the -soft option is used, requests to reinstall the trigger nodes can time out. The failure to reinstall the trigger nodes leaves no access to the next level of mounts. The only way to clear this problem is to have the automounter unmount all of the components in the hierarchy. The automounter can complete the unmount either by waiting for the file systems to be automatically unmounted or by rebooting the system.

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

The example direct map contains the following:

/usr/local          -ro \
   /bin                   ivy:/export/local/sun4\
   /share                 ivy:/export/local/share\
   /src                   ivy:/export/local/src
/usr/man            -ro   oak:/usr/man \
                          rose:/usr/man \
                          willow:/usr/man
/usr/games          -ro   peach:/usr/games
/usr/spool/news     -ro   pine:/usr/spool/news \
                          willow:/var/spool/news 

The mount points /usr/man and /usr/spool/news list more than one location, three locations for the first mount point, two locations for the second mount point. This means any of the replicated locations can provide the same service to any user. This procedure is sensible only when you mount a file system that is read-only, as you must have some control over the locations of files that you write or modify. You don't want to modify files on one server on one occasion and, minutes later, modify the “same” file on another server. The benefit is that the best available server is used automatically without any effort that is required by the user.

If the file systems are configured as replicas (see What Is a Replicated File System?), the clients have the advantage of using failover. Not only is the best server automatically determined, but if that server becomes unavailable, the client automatically uses the next-best server. Failover was first implemented in the Solaris 2.6 release.

An example of a good file system to configure as a replica is man pages. In a large network, more than one server can export the current set of man pages. Which server you mount the man pages from does not matter if 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 

In this example, you can mount the man pages from the servers oak, rose, or willow. Which server is best depends on a number of factors, including the following:

• The number of servers that support a particular NFS protocol level

• The proximity of the server

• The weighting

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

After the largest subset of servers with the same protocol version is found, that server list is sorted by proximity. Servers on the local subnet are given preference over servers on a remote subnet. The closest server is given preference, which reduces latency and network traffic. Figure 15–3 illustrates server proximity.

Figure 15–3 Server Proximity

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

If version 3 servers are more abundant, the sorting process becomes more complex. Normally, servers on the local subnet are given preference over servers on a remote subnet. A version 2 server can complicate matters, as a version 2 server might be closer than the nearest version 3 server. If a version 2 server is on the local subnet and the closest version 3 server is on a remote subnet, the version 2 server is given preference. This preference is only checked if more version 3 servers exist than version 2 servers. If more version 2 servers exist, only a version 2 server is selected.

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

This feature is particularly useful in a large network with many subnets. Autofs chooses the nearest server and therefore confines NFS network traffic to a local network segment. In servers with multiple network interfaces, list the host name that is associated with each network interface as if the interface were a separate server. Autofs selects the nearest interface to the client.

Autofs and Weighting

You can influence the selection of servers at the same proximity level by adding a weighting value to the autofs map. For example:

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

The numbers in parentheses indicate a weighting. Servers without a weighting have a value of zero and, therefore, are most likely to be selected. The higher the weighting value, the lower the chance that the server is selected.

All other server selection factors are more important than weighting. Weighting is only considered when selecting between servers with the same network proximity.

Variables in a Map Entry

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

You can use variables anywhere in an entry line except as a key. For instance, suppose that you have a file server that exports binaries for SPARC and IA architectures from /usr/local/bin/sparc and /usr/local/bin/x86 respectively. The clients can mount through a map entry such as the following:

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

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

Most applications that are written for any of the sun4 architectures can run on all sun4 platforms, so the -ARCH variable is hard-coded to sun4 instead of sun4m.

Maps That Refer to Other Maps

A map entry +mapname that is used in a file map causes automount to read the specified map as if it were included in the current file. If mapname is not preceded by a slash, autofs treats the map name as a string of characters and uses the name-service switch policy to find the map name. If the path name is an absolute path name, automount checks a local map of that name. If the map name starts with a dash (-), automount consults the appropriate built-in map, such as hosts.

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

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

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

In this example, the local maps are searched before the NIS maps. Therefore, you can have a few entries in your local /etc/auto_home map for the most commonly accessed home directories. You can then use the switch to fall back to the NIS map for other entries.

bill               cs.csc.edu:/export/home/bill
bonny              cs.csc.edu:/export/home/bonny

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

bill               cs.csc.edu:/export/home/bill
bonny              cs.csc.edu:/export/home/bonny
+auto_home 

The map that is included can be a local file or a built-in map. Remember, only local files can contain + entries.

+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 

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

Executable Autofs Maps

You can create an autofs map that executes some commands to generate the autofs mount points. You could benefit from using an executable autofs map if you need to be able to create the autofs structure from a database or a flat file. The disadvantage to using an executable map is that the map needs to be installed on each host. An executable map cannot be included in either the NIS or the NIS+ name service.

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

/execute    auto_execute

Here is an example of an executable map:

#!/bin/ksh
#
# executable map for autofs
#

case $1 in
	         src)  echo '-nosuid,hard bee:/export1' ;;
esac

For this example to work, the file must be installed as /etc/auto_execute and must have the executable bit set. Set permissions to 744. Under these circumstances, running the following command causes the /export1 file system from bee to be mounted:

% ls /execute/src

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 are effective the next time automountd mounts a file system depends on which map you modify and what kind of modification you make.

Default Autofs Behavior With Name Services

Booting invokes autofs by using the /etc/init.d/autofs script and checks for the master auto_master map. Autofs is subject to the rules that are discussed subsequently.

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

Figure 15–4 How Autofs Uses the Name Service

The screen activity for this session would resemble the following example.

$ grep /home /etc/auto_master
/home           auto_home

$ ypmatch brent auto_home
Can't match key brent in map auto_home.  Reason: no such map in
server's domain.

$ ypmatch brent auto.home
diskus:/export/home/diskus1/&

If “files” is selected as the name service, all maps are assumed to be local files in the /etc directory. Autofs interprets a map name that begins with a slash (/) as local regardless of which name service autofs uses.

Autofs Reference

The remaining sections of this chapter describe more advanced autofs features and topics.

Metacharacters

Autofs recognizes some characters as having a special meaning. Some characters are used for substitutions, and some characters are used 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 the key appears. If you use the ampersand, the previous map changes to the following:

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

You could also use key substitutions in a direct map, in situations such as the following:

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

You can also simplify the entry further as follows:

/usr/man						willow,cedar,poplar:&

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

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

The reason is that autofs would interpret the example as the following:

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

Asterisk (*)

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

*						&:/export

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

Special Characters

If you have a map entry that contains special characters, you might have to mount directories that have names that confuse the autofs map parser. The autofs parser is sensitive to names that contain 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 - "