Part II All About NFS Services

This part of the manual describes most of the the NFS services and how to administer them. The next part covers autofs.

• "Automatic File-System Sharing"

• "Mounting File Systems"

• "Setting Up NFS Services"

• "Administering the Secure NFS System"

• "WebNFS Administration Tasks"

• "NFS Troubleshooting Procedures"

• "NFS Error Messages"

• "NFS Files"

• "NFS Daemons"

• "NFS Commands"

Chapter 2 NFS Administration

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

• "Automatic File-System Sharing"

• "Mounting File Systems"

• "How to Start the NFS Services"

• "How to Disable Large Files on an NFS Server"

• "How to Use Client-Side Failover"

• "Administering the Secure NFS System"

• "WebNFS Administration Tasks"

• "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 case you might be responsible for determining these configuration items:

• Which computers, if any, should be dedicated servers

• Which computers should act as both servers and clients

• Which computers should be clients only

Maintaining a server once 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 them over the NFS environment. You specify which file systems are to be shared with the share command and/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 diskless clients, you need to make your clients' root 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 and controls which clients can mount a file system. If you want to modify dfstab to add or delete a file system or to modify the way sharing is done, simply edit the file with any supported text editor (such as vi). The next time 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 you would 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. Edit the /etc/dfs/dfstab file.

   Add one entry to the file for each file system that you want to have shared automatically. Each entry must be on a line by itself in the file and uses this syntax:

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

2. Check that the NFS service is running on the server.

   If this is the first share command or set of share commands that you have initiated, it is likely that the NFS daemons are not running. The following commands kill the daemons and restart them.

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

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

   At this point, set up your autofs maps so that clients can access the file systems you've shared on the server. See "Setting Up Autofs".

Mounting File Systems

There are several ways to mount file systems. They 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, but many situations require a combination of all three.

How to Mount at Boot Time

If you want to mount file systems at boot time instead of using autofs maps, follow this procedure. Although you must follow this procedure for all local file systems, it is not recommended for remote file systems because it must be completed on every client.

Edit the /etc/vfstab file.

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

special  fsckdev  mountp  fstype  fsckpass  mount-at-boot  mntopts

Example of a vfstab entry

You want a client computer to mount the /var/mail directory on the server wasp. You would like it mounted as /var/mail on the client. 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

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, so that if you have two servers fail at the same time that are mounting file systems from each other, each system could hang as the systems reboot.

How to Mount From the Command Line

To manually mount a file system during normal operation, run the mount command as superuser:

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

In this case, 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.

The version of the mount command released in Solaris 2.6 and in future patches will not warn about invalid options. The command silently ignores any options that cannot be interpreted. Make sure to verify all of the options that were used to prevent unexpected behavior.

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. Run the nfsstat command to verify the options.

   # 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

   Note that 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, but 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, so verifying that the options listed in the file match those listed on the command line is a way to check those options not reported by the nfsstat command.

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

How to Mount With the Automounter

Chapter 5, About Autofs 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, all you would need to do is:

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

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

Setting Up NFS Services

This section discusses some of the tasks necessary to initialize or use NFS services.

How to Start the NFS Services

To enable daemons without rebooting, become superuser and type the following command.

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

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

How to Stop the NFS Services

To disable daemons without rebooting, become superuser and type the following command.

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

How to Disable Large Files on an NFS Server

1. 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 there are large files on the file system, you must remove or move them to another file system.

2. Unmount the file system.

   # umount /export/home1

3. Reset the file system state if the file system has been mounted using -largefiles.

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

   # fsck /export/home1

4. Mount the file system using -nolargefiles.

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

   You can do this from the command line, but to make the option more permanent, add an entry like the following into /etc/vfstab:

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

   ---

   Note -

   Previous versions of the Solaris operating system cannot use large files. Check that clients of the NFS server are running at least version 2.6 if the clients need to access large files.

   ---

How to Use Client-Side Failover

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

You can do this from the command line, through the automounter, or by adding an entry to /etc/vfstab that looks like:

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

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

Servers that are running different versions of the NFS protocol can not be mixed using a command line or in a vfstab entry. Mixing servers supporting NFS V2 and V3 protocols can only be done with autofs, in which case the best subset of version 2 or version 3 servers is used.

How to Disable Mount Access for One Client

1. Edit /etc/dfs/dfstab.

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

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

   For additional information on access lists, see "Setting Access Lists With the share Command".

2. Run the shareall command.

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

   # shareall

Administering the Secure NFS System

To use the Secure NFS system, all the computers you are responsible for must have a domain name. A domain is an administrative entity, typically consisting of several computers, that joins a larger network. If you are running NIS+, you should also establish the NIS+ name service for the domain. See Solaris Naming Setup and Configuration Guide.

You can configure the Secure NFS environment to use either Diffie-Hellman or Kerberos Version 4 authentication or a combination of the two. The System Administration Guide discusses these authentication services.

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 Solaris Naming Administration Guide if you are using NIS+ as your name service.

2. Establish public keys and secret keys for your clients' users using the newkey or nisaddcred command, and have each user establish his or her own secure RPC password 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 and secret keys have been generated, the public 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. To verify that the keyserv daemon (the keyserver) is running, type the following:

   # 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, to start the keyserver, type the following:

   # /usr/sbin/keyserv

5. Run keylogin to decrypt and store the secret key.

   Usually, the login password is identical to the network password. In this case, 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 only need to run keylogin -r if the root secret key changes or /etc/.rootkey is lost.

   ---

6. Edit the /etc/dfs/dfstab file and add the -sec=dh option to the appropriate entries (for Diffie-Hellman authentication).

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

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

   With Solaris 2.5 and earlier releases, if a client does not mount as secure a file system that is shared as secure, users have access as user nobody, rather than as themselves. With Version 2 on the Solaris 2.6 release, the NFS server will refuse access if the security modes do not match, unless -sec=none is included on the share command line. With version 3, the mode will be inherited from the NFS server, so there is no need for the clients to specify -sec=krb4 or -sec=dh. The users will have access to the files as themselves.

   ---

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

   # keylogin -r

How to Set Up a Secure NFS Environment With KERB Authentication

1. Edit the /etc/dfs/dfstab file and add the -sec=krb4 option to the appropriate entries.

   # share -F nfs -o sec=krb4 /export/home

2. Edit the auto_master data to include -sec=krb4 as a mount option.

   /home auto_home -nosuid,sec=krb4

   ---

   Note -

   With Solaris 2.5 and earlier releases, if a client does not mount as secure a file system that is shared as secure, users have access as user nobody, rather than as themselves. With Version 2 on the Solaris 2.6 release, the NFS server will refuse access if the security modes do not match, unless -sec=none is included on the share command line. With version 3, the mode will be inherited from the NFS server, so there is no need for the clients to specify -sec=krb4 or -sec=dh. The users will have access to the files as themselves.

   ---

WebNFS Administration Tasks

This section provides instructions for administering the WebNFS system. The following tasks are discussed.

• "Planning for WebNFS Access"

• "How to Enable WebNFS Access"

• "How to Browse Using an NFS URL"

• "How to Enable WebNFS Access Through a Firewall"

Planning for WebNFS Access

To use the WebNFS functionality, you first need an application capable of running and loading an NFS URL (for example, nfs://server/path). The next step is to choose the file system that will be exported for WebNFS access. If the application is web browsing, often the document root for the web server is used. Several factors need to be considered 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, then 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 servers' root file system. By default the public file handle points to the root file system, but this file handle does not allow web access unless the root file system is shared.

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

3. File systems that are already open to the public make good candidates for using the -public option, like 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 instead of listing 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 provides the correct level of access.

   Additional factors need to be considered if both NFS and HTTP URLs are going to be used to access one Web site. These are described in "WebNFS Limitations With Web Browser Use".

How to Enable WebNFS Access

By default in the 2.6 release, all file systems that are available for NFS mounting are automatically available for WebNFS access. The only time that this procedure needs to be followed is on servers that do not already allow NFS mounting, if resetting the public file handle is useful to shorten NFS URLs, or if the -index option is required.

1. Edit the /etc/dfs/dfstab file.

   Add one entry to the file for the file system that you want to have shared automatically. The -index tag is optional.

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

2. Check that the NFS service is running on the server.

   If this is the first share command or set of share commands that you have initiated, it is likely that the NFS daemons are not running. The following commands kill and restart the daemons.

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

3. Share the file system.

   Once 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 daemons were restarted in step 2, then this command does not need to be run because the script runs the command.

   # shareall

4. 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 Browse Using an NFS URL

Browsers capable of supporting WebNFS access should provide access using an NFS URL that looks something like:

nfs://server<:port>/path

server is the name of the file server, port is the port number to use (the default value is 2049), and path is the path to the file. Path can either be relative to the public file handle or relative to the root file system on the server.

In most browsers, the URL service type (for example, nfs or http) is remembered from one transaction to the next, unless a URL that includes a different service type is loaded. When using NFS URLs, if a reference to a HTTP URL is loaded, then subsequent pages are loaded using the HTTP protocol instead of the NFS protocol, unless the URLs specify an NFS URL.

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. Simply allowing access for httpd does not allow NFS URLs to be used.

Strategies for NFS Troubleshooting

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

The mountd and nfsd daemons start automatically at boot time only if there are NFS share entries in the /etc/dfs/dfstab file. Therefore, mountd and nfsd must be started manually when setting 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 it with the keyboard interrupt Control-c.

When the network or server has problems, programs that access hard-mounted remote files fail differently than those 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 a while. 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 it hangs if the server fails to respond. In this case, 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 accessing 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, it might become apparent that other portions of the network are not functioning, such as the name service or the physical network hardware. The Solaris Naming Administration Guide contains debugging procedures for the NIS+ name service. Also, during the process it might become obvious that the problem isn't at the client end (for instance, if you get at least one trouble call from every subnet in your work area). In this case, it is much more timely to assume that the problem is the server or the network hardware near the server, and 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 Remotely Check the NFS Server").

2. If the server is not reachable from the client, make sure 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, make sure 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 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 Remotely Check the NFS Server

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 nfs superuser 100005 3,2,1 ticots,ticotsord,tcp,ticlts,udp 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.

   % /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 fails, skip 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

   Using the -t option tests the TCP connection. If either attempt fails, skip 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 doesn't work, 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 name space. In this instance, if the first client is not in the eng netgroup, then that client would not be able to mount the /usr/src file system.

   Check all entries that include mounting informtion 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. Log on to the server as root.

2. Check that the server can reach the clients.

   # ping lilac lilac is alive

3. If the client is not reachable from the server, make sure 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 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

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

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

   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 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 rpcbind seems to be hung, either reboot the server or follow the steps in "How to Warm-Start rpcbind".

How to Restart NFS Services

To enable daemons without rebooting, become superuser and type the following commands.

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

This stops the daemons and restart them, if there is an entry in /etc/dfs/dfstab.

How to Warm-Start rpcbind

If the NFS server can not be rebooted because of work in progress, it is possible to restart rpcbind without having to restart all of the services that use RPC by completing a warm start as described in this procedure.

1. As root on the server, get 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

2. 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 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, then you cannot complete a warm start of rpcbind and will have to reboot the server to restore service.

   ---

3. Restart rpcbind.

   Do a warm restart of the command so that the files created by the kill command are consulted, and the process resumes without requiring that all of the RPC services be restarted (see the rpcbind(1M) man page).

   # /usr/sbin/rpcbind -w

How to Identify 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

NFS Error Messages

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 name space has not been updated. It can also be reported for UDP. To fix this problem, you must update the services data in the name space. For NIS+ the entries should be:

nfsd nfsd tcp 2049 NFS server daemon nfsd nfsd ucp 2049 NFS server daemon

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

nfsd 2049/tcp nfs # NFS server daemon nfsd 2049/ucp 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 for the -index option to work.

---

Note -

Releases prior to 2.6 required that the public file handle be set using the share command. Since the Solaris 2.6 release sets the public file handle to be / by default, this error message is no longer relevant.

---

NOTICE: NFS3: failing over from host1 to host2

This message is displayed on the console when a failover has occurred. It is an advisory message 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 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

mount 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 allowed access to the file system you want to mount. Use showmount -e to verify the access list.

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 the 2.6 version of the mount command or in earlier versions that have been patched.

---

nfs mount: NFS can't support "nolargefiles"

A Solaris 2.6 NFS client has attempted to mount a file system from an NFS server 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 be dead. This message indicates that NFS server hostname is down or that there is a problem with the server or with the network. If failover is being used, then hostname is a list of servers. Start with "How to Check Connectivity on an NFS Client".

NFS fsstat failed for server hostname: RPC: Authentication error

This error can be caused by many situations. One of the most difficult to debug is when this occurs because a user is in too many groups. Currently a user can be in as many as 16 groups but no more if they are accessing files through NFS mounts. If a user must have the functionality of being in more than 16 groups and if Solaris 2.5 is running on the NFS server and the NFS clients, then use ACLs to provide the needed access privileges.

relicas 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 version 2 and version 3 servers 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 would increase the likelihood that a file will 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 the /etc/dfs/dfstab file to make sure that only one file system is 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 is not going to work.

Chapter 3 NFS Reference

This chapter provides an introduction to the NFS commands. This chapter also provides 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 It All Works Together"

NFS Files

You need several ASCII files to support NFS activities on any computer. Table 3-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.

There is only one entry 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.

NFS Daemons

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

The other two daemons (lockd and statd) are run on NFS clients to support NFS file locking. These daemons must also run on the NFS servers.

lockd

This daemon supports record-locking operations on NFS files. It will send locking requests from the client to the NFS server. On the NFS server, it will start local locking. The daemon is normally started without any options. You can use three options with this command (see the lockd(1M) man page).

The -g graceperiod option selects the number of seconds that the clients have to reclaim locks after a server reboot. During this time, the NFS server will only process 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 can be 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, but it increases the chances that a client might not be able to recover all its locks.

The -t timeout option 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, but it can cause additional server load by increasing the frequency of lock requests.

The nthreads option specifies the maximum number of concurrent threads that the server will handle per connection. Base the value for nthreads should on the load expected on the NFS server. The default value is 20. Since each NFS client using TCP uses a single connection with the NFS server, each TCP client will be granted the ability to use up to 20 concurrent threads on the server. All NFS clients using UDP will share a single connection with the NFS server. Under these conditions it might be necessary to increase the number of threads available for the UDP connection. A minimum calculation would be to allow for two threads for each UDP client, but this 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 will be used on the NFS server, but if the threads are never used increasing nthreads will have no effect.

mountd

This is a remote procedure call (RPC) server that handles file system mount requests from remote systems and provides access control. It checks /etc/dfs/sharetab to determine which file systems are available for remote mounting and which systems are allowed to do the remote mounting. Two options might be used with this command (see the mountd(1M) man page).

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

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

nfsd

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.

The -l option sets the connection queue length for the NFS/TCP over connection-oriented transports. The default value is 32 entries.

The -c #_conn option selects the maximum number of connections per connection-oriented transport. The default value for #_conn is unlimited.

The nservers option is the maximum number of concurrent requests that a server can handle. The default value for nservers is 1, but the startup scripts select 16.

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.

statd

This daemon works with lockd to provide crash and recovery functions for the lock manager. It keeps track of the clients that hold locks on an NFS server. If a server crashes, upon 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. There are no options to select with this daemon. For more information see the statd(1M) man page.

NFS Commands

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

• "clear_locks"

• "mount"

• "mountall"

• "setmnt"

• "share"

• "shareall"

• "showmount"

• "umount"

• "umountall"

• "unshare"

• "unshareall"

clear_locks

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 and 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 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. It must be run from the NFS client, which created the locks. In this case, the locks from the client would be removed from the NFS server 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

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. For a complete description of all of the file system types, see the System Administration Guide. 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 it is mount_ufs(1M); and so forth.

The version of the mount command released in Solaris 2.6 and in future patches will not warn about invalid options. The command will silently ignore any options that can not be interpreted. Make sure to verify all of the options that were used to prevent unexpected behavior.

mount Options for NFS File Systems

The subsequent text lists some of the options that can follow the -o flag when mounting an NFS file system.

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. It prevents further processing until the mount is complete. -bg is a good selection for file systems that are not critical, because the client will do other processing while waiting for the mount request to complete.

largefiles

This option makes it possible to access files larger than 2 Gbytes on a server 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. By default, all 2.6 UFS file systems are mounted with -largefiles. For mounts using the NFS version 2 protocol, the -largefiles option causes the mount to fail with an error.

nolargefiles

This option for UFS mounts guarantees that there are and will be no large files 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, there is no option for -nolargefiles using NFS mounts. Attempts to NFS mount a file system using this option will be rejected with an error.

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 shown in Table 3-2. The modes are also defined in /etc/nfssec.conf.

Table 3-2 NFS Security Modes

Mode	Authentication Service Selected
krb4	Kerberos Version 4
none	No authentication
dh	Diffie-Hellman (DH) authentication
sys	Standard UNIX authentication

soft|hard

An NFS file system 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. Even if the application does check, routing problems and other conditions can still confuse the application or lead to file corruption if the soft option is used. In most cases the soft option should not be used. If a file system is mounted using the hard option and becomes unavailable, an application using this file system will hang until the file system becomes available.

Using the mount Command

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

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 on:

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

This command uses client failover:

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

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, in which case the best subset of version 2 or version 3 servers is used.

Use the mount command with no arguments to display file systems 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

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, then those file systems are unmounted. If no mount points are included, then an attempt is made to unmount all file systems 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 command will not succeed if the file system is in use. For instance, if a user has used cd to get access to a file system, the file system will be busy until the working directory is changed. The umount command may hang temporarily if the NFS server is unreachable.

Using the umount Command

This example unmounts a file system 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

Note that this command will not actually unmount the file systems.

mountall

Use this command to mount all file systems or a specific group of file systems listed in a file system table. The command provides a way to select the file system type to be accessed with the -F FSType option, to select all the remote file systems listed in a file system table with the -r option, and to select all the local file systems with the -l option. Because all file systems labeled as NFS file system type are remote file systems, some of these options are redundant. For more information, see the mountall(1M) man page.

Using the mountall Command

These two examples are equivalent:

# mountall -F nfs

# mountall -F nfs -r

umountall

Use this command to unmount a group of file systems. The -k option indicates that the fuser -k mount_point command should be used to kill any processes 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 currently mounted from the server bee:

# umountall -h bee

share

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 for the share command to work. The NFS server software is started automatically during boot if there is an entry in /etc/dfs/dfstab. The command will not report an error if the NFS server software is not running, so you must check this yourself.

The objects that can be shared include any directory tree, but 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 they 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 that is part of a larger file system that is already shared. For example, if /usr and /usr/local are on one disk slice, then /usr can be shared or /usr/local can be shared, but if both need to be shared with different share options, then /usr/local will need to be moved to a separate disk slice.

You can gain access to a file system that is shared read-only through the file handle of a file system that is shared read-write if the two file systems are on the same disk slice. It is more secure to place those file systems that need to be read-write on a separate partition or disk slice than the file systems that you need to share read-only.

share Options

Some of the options that you can include with the -o flag are:

rw|ro

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

rw=accesslist

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

The options that you can use with NFS file systems only include:

aclok

This option enables an NFS server supporting the NFS version 2 protocol to be configured to do access control for NFS version 2 clients (running SunOS 2.4 or earlier releases). Without this option all clients are given minimal access. With this option the clients have maximal access. For instance, on file systems shared with the -aclok option, if anyone has read permissions, then everyone does. However, without this option, it is possible to deny access to a client who should have access permissions. Whether it is preferred to permit too much access or to permit too little, will depend on the security systems already in place. See the System Administration Guide for more information about access control lists (ACLs).

---

Note -

To take advantage of ACLs, it is best to have 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, then clients will get correct access, but will not be able to manipulate the ACLs. If the software supports the NFS_ACL protocol, then the clients will get correct access and the capability to 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 will allow unauthenticated users to have root access, so use the root option instead.

index=filename

You can use the -index=filename option to force the loading of a HyperText Markup Language (HTML) file instead of displaying a listing of the directory when a user accesses an NFS URL. This option will mimic the action of current browsers if an index.html file is found in the directory that the HTTP URL is accessing. This is the equivalent of setting the DirectoryIndex option for httpd. For instance, if the dfstab file entry looks like:

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

these URLs will 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

nosuid

This option signals that all attempts to enable the setuid or setgid mode should be ignored. NFS clients will not be able to 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 may 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, then you can only include client host names in the accesslist. The list of clients defined in accesslist has been expanded for the Solaris 2.6 release. See "Setting Access Lists With the share Command" for more information.

---

Caution -

Granting root access to other hosts has far-reaching security implications; use the root= option with extreme caution.

---

sec=mode[:mode]

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

window=value

value selects the maximum life time 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 OS releases prior to 2.6, the accesslist included with either the -ro=, -rw=, or -root= option of the share command were restricted to a list of host names or netgroup names. In 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 make it easier to control file access control on a single server, without having to change the name space 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 enter all options on the same line, as multiple invocations of the share command on the same object "remember" only the last command 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 using multiple authentication mechanisms, make sure to 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 named eng. These hosts can only mount the file system in read-only mode. The hosts tulip and lilac will be able to mount the file system read-write if they use Diffie-Hellman authentication. With these options, tulip and lilac will be able to mount the file system read-only even if they are not using DH authentication, if the host names are 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, it is not included if the -sec option is used, so it is important to 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 dot indicates that the string following it is a domain name, not a fully qualified host name. The following entry will allow mount access to all hosts in the eng.sun.com domain:

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

In this example, the single "." matches all hosts that are matched through the NIS or NIS+ name spaces. The results returned from these name services do not include the domain name. The ".eng.sun.com" entry matches all hosts that use DNS for name space 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 name spaces.

You can use a subnet number in an access list by preceding the actual network number or the network name with "@". This differentiates the network name from a netgroup or a fully qualified host name. You must identify the subnet in either /etc/networks or in a NIS or NIS+ name space. The following entries will 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 it is not necessary 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 because the entries are read from left to right, you must place the negative access entries before the entry they are to apply to:

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

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

unshare

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, remember that it will be shared again when you exit and re-enter 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 will not be accessible.

Using the unshare Command

This command unshares a specific file system:

# unshare /usr/src

shareall

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, then you can type share commands from standard input.

Using the shareall Command

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

# shareall /etc/dfs/special_dfstab

unshareall

This command makes all currently shared resources unavailable. The -F FSType option selects a list of file system types 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

This command displays all the clients that have remotely mounted file systems that are shared from an NFS server, or only the file systems that are mounted by clients, or the shared file systems with the client access information. The command syntax is:

showmount [ -ade ] [ hostname ]

where -a prints a list 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 shared (or exported), and hostname selects the NFS server to gather the information from. If hostname is not specified then the local host is queried.

Using the showmount Command

This command lists all clients and the directory that they 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

This command creates an /etc/mnttab table. The mount and umount commands consult the table. Generally, there is no reason to run this command manually; it is run automatically when a system is booted.

Other Useful Commands

These commands can be useful when troubleshooting NFS problems.

• "nfsstat"

• "pstack"

• "rpcinfo"

• "snoop"

• "truss"

nfsstat

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

nfsstat [ -cmnrsz ]

where -c displays client-side information, -m displays statistics for each NFS-mounted file system, -n specifies that NFS information is to be displayed (both client and server side), -r displays RPC statistics, -s displays the server-side information, and -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 hardware is added to the computing environment. Running this command at least 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%

This is an example of NFS server statistics. The first five lines deal with 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 when something is going wrong. The badcalls value reports the number of bad messages from a client and 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 to 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 one, check that the NFS clients have enough memory. The number of commit operations on the server go up when clients do not have resources available.

pstack

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

The example below 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

It shows that the process is waiting for a new connection request. This is a normal response. If the stack shows that the process is still in poll after a request is made, it is possible that the process is 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

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

rpcinfo [ -m | -s ] [ hostname ]

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

where -m displays a table of statistics of the rpcbind operations, -s displays a concise list of all registered RPC programs, -t displays the RPC programs that use TCP, -u displays the RPC programs that use UDP, hostname selects the host name of the server you need information from, and progname selects the RPC program to gather information about. If no value is given for hostname, then the local host name is used. You can substitute the RPC program number for progname, but many users will 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 generated by this command can include:

• 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 running on a server. The text generated by the command is filtered by the sort command to make it more readable. Several lines listing RPC services have been deleted from the example.

% rpcinfo -s bee |sort -n
   program version(s) netid(s)                         service     owner
    100000  2,3,4     udp,tcp,ticlts,ticotsord,ticots  portmapper  superuser
    100001  4,3,2     ticlts,udp                       rstatd      superuser
    100002  3,2       ticots,ticotsord,tcp,ticlts,udp  rusersd     superuser
    100003  3,2       tcp,udp                          nfs         superuser
    100005  3,2,1     ticots,ticotsord,tcp,ticlts,udp  mountd      superuser
    100008  1         ticlts,udp                       walld       superuser
    100011  1         ticlts,udp                       rquotad     superuser
    100012  1         ticlts,udp                       sprayd      superuser
    100021  4,3,2,1   ticots,ticotsord,ticlts,tcp,udp  nlockmgr    superuser
    100024  1         ticots,ticotsord,ticlts,tcp,udp  status      superuser
    100026  1         ticots,ticotsord,ticlts,tcp,udp  bootparam   superuser
    100029  2,1       ticots,ticotsord,ticlts          keyserv     superuser
    100068  4,3,2     tcp,udp                          cmsd        superuser
    100078  4         ticots,ticotsord,ticlts          kerbd       superuser
    100083  1         tcp,udp                          -           superuser
    100087  11        udp                              adm_agent   superuser
    100088  1         udp,tcp                          -           superuser
    100089  1         tcp                              -           superuser
    100099  1         ticots,ticotsord,ticlts          pld         superuser
    100101  10        tcp,udp                          event       superuser
    100104  10        udp                              sync        superuser
    100105  10        udp                              diskinfo    superuser
    100107  10        udp                              hostperf    superuser
    100109  10        udp                              activity    superuser
	.
	.
    100227  3,2       tcp,udp                          -           superuser
    100301  1         ticlts                           niscachemgr superuser
    390100  3         udp                              -           superuser
1342177279  1,2       tcp                              -           14072

This example shows how to gather information about a particular RPC service using 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 running over TCP. The second example checks the NFS service running over UDP.

snoop

This command is often used to watch for packets on the network. It must be run as root. It is a good way to make sure 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 is given below:

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

where -d device specifies the local network interface, -o filename stores all the captured packets into the named file, and hostname indicates to display only packets going to and from a specific host.

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 host that you expect them to. Also, look for error messages. Saving the packets to a file can make it much easier to review the data.

truss

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

truss [ -t syscall ] -p pid

where -t syscall selects system calls to trace, and -p pid indicates the PID of the process to be traced. The syscall may be a comma-separated list of system calls to be traced. Also, starting syscall with a ! selects to exclude the 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...)

This is 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 It All Works Together

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

Version 2 and Version 3 Negotiation

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

You can override the values determined by the negotiation by using the -vers option to 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 one will be selected by default.

UDP and TCP Negotiation

During initiation, the transport protocol is also negotiated. By default, the first connection-oriented transport supported on both the client and the server is selected. If this does not succeed, then the first available connectionless transport protocol is used. The transport protocols supported on a system are listed in /etc/netconfig. TCP is the connection-oriented transport protocol supported by the Solaris 2.6 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 using UDP will be given higher precedence than the NFS version 2 protocol 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, it is better to 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, but the Solaris 2.6 release 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 is not necessary.

The transfer size is not negotiated with systems using 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 manually set the transfer size 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.

Client-Side Failover

Using client-side failover, an NFS client can switch to another server if the server supporting a replicated file system becomes unavailable. The file system can become unavailable if the server it is connected to crashes, if the server is overloaded or if there is a network fault. The failover, under these conditions, will normally be transparent to the user. Once established the failover can occur at any time without disrupting the processes 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 one that is not changed often is the best candidate for failover.

You can not use file systems that are mounted using cachefs with failover. Extra information is stored for each cachefs file system. This information can not be updated during failover, so only one of these two features may be used when mounting a file system.

The number of replicas that need to be established for each file system depends on many factors. In general, it is better to have a couple of servers, each supporting multiple subnets rather than have a unique server on each subnet. The process requires checking of each server in the list, so the more servers that are listed the slower each mount will be.

Failover Terminology

To fully comprehend the process, two terms need to be understood.

• failover - Selecting a server from a list of servers supporting a replicated file system. Normally, the next server in the sorted list is used, unless it fails to respond.

• remap - Making 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 may 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, then the remap will fail and the process will hang until the old server becomes available.

You can maintain a replicated file system using rdist, cpio, or other file transfer mechanisms. Because updating the replicated file systems will cause inconsistency, follow these suggestions for best results:

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

• 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 will persist through a remap because the server doesn't "know" about them. Because the files should not be changing, you do not need to lock the file on the server side.

Large Files

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

No changes need to occur on a Solaris 2.6 NFS client to be able to access a large file, if the file system on the server is mounted with the -largefiles option. However, not all 2.6 commands will be able to 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 will be unable to access any large files. Although clients running the Solaris 2.5 release can use the NFS version 3 protocol, large file support was not included in that release.

How the WebNFS Service Works

The WebNFS service makes files in a directory available to clients using a public file handle. A file handle is simply an address generated by the kernel that identifies a file for NFS clients. The public file handle has a predefined value, so there is no need for the server to generate a file handle for the client. The ability to use this predefined file handle reduces network traffic by eliminating the MOUNT protocol and should increase response time for the clients.

By default the public file handle on an NFS server is established on the root file system. This default will provide 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 transaction, called multicomponent lookup, when the LOOKUP is relative to the public file handle. With multicomponent lookup, the WebNFS server is able to deliver the file handle to the desired file without having to exchange 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, which provides quick access without the additional load on the server 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 will be 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 would be equivalent if the public file handle has been established on the /export/ftp file system.

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

WebNFS Limitations With Web Browser Use

There are several functions that a Web site using HTTP can provide that are not supported by the WebNFS software. These differences are caused by the fact that the NFS server will only send the file, so any special processing must be done on the client. If you need to have one Web site that is configured for both WebNFS and HTTP access, then 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, to handle files in different file formats. Accessing these files through an NFS URL will start an external viewer as long as 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. Because the WebNFS software does not check inside the file to determine the file type--unlike some Web browser applications--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, it 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.

The Secure NFS System

The NFS environment is a powerful 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 making the request, but not the user, so a client user can run su and impersonate the owner of a file. If DH authentication is used, the NFS server will authenticate 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 involving the introduction of data, such as impersonating a user by generating the right packets or recording "conversations" and replaying them later. These attacks affect data integrity. Attacks involving 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 goes 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 system 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 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 at least as secure as a time-sharing system (one in which 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 is true. Users can log in on any remote computer just as they can on a local terminal, and their 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 in order 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 attached to the badge: you can be sure the badge has not been stolen by checking the photo on the badge against the person carrying it. 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 may be plugged into it. Currently, there are three systems: UNIX, DH, and KERB (for Kerberos Version 4).

When UNIX authentication is used by a network service, the credentials contain the client's host name, UID, GID, and group-access list, but the verifier contains nothing. Because there is no verifier, a superuser could falsify appropriate credentials, using commands such as su. Another problem with UNIX authentication is that it 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 either DH authentication or KERB 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 and secret keys are stored in the name space. NIS stores the keys in the publickey map, and NIS+ stores the keys in the cred table. These maps contain the public key and secret key for all potential users. See the System Administration Guide for more information on how to set up the maps and tables.

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 time stamp is encrypted with DES. There are two requirements for this scheme to work:

• 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, then the time on the client and the server is synchronized automatically. If a time synchronization program is not available, time stamps can be computed 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 time stamps. 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 then 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 time stamp; the common key is used to encrypt and decrypt the conversation key.

KERB Authentication

Kerberos is an authentication system developed at MIT. Encryption in Kerberos is based on DES.

Kerberos works by authenticating the user's login password. A user types the kinit command, which obtains a ticket that is valid for the time of the session (or eight hours, the default session time) from the authentication server. When the user logs out, the ticket may be destroyed using the kdestroy command.

The Kerberos server software is available from MIT Project Athena, and is not part of the SunOS software. SunOS software provides

• Routines used by the client to create, acquire, and verify tickets

• An authentication option to Secure RPC

• A client-side daemon, kerbd

See the System Administration Guide for more details.

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, so 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. Before that, there is no way to authenticate the replies given by the boot server. This could be a serious problem, but it requires a sophisticated attack, using kernel source code. Also, the crime would have 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 root's secret key is stored in /etc/.rootkey, these programs behave as they always have. If a setuid program is owned by a user, however, it may not always work. For example, if a setuid program is owned by dave and dave has not logged into the computer since it booted, then 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. This is because your secret key gets passed to that computer's key server, which then stores it. This is only a concern if you don't trust the remote computer. If you have doubts, however, don't log in to a remote computer if it requires a password. Instead, use the NFS environment to mount file systems 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 or -o sec=krb4 options, then remote logins can be a problem. If the /etc/hosts.equiv or ~/.rhosts files are set to not prompt for a password, the login will succeed, but the user will not be able to access their home directory because no authentication has occurred locally. If the user is prompted for a password, then as long as the password matches the network password, the user will have access to their home directory.