System Administration Guide, Volume 3

NFS Commands

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


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

automount [ -t duration ] [ -v ]

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

If not specifically set, the value for duration is set to 5 minutes. In most circumstances this is a good value; however, on systems that have many automounted file systems, you might need to increase the duration value. In particular, if a server has many users active, checking the automounted file systems every 5 minutes can be inefficient. Checking the autofs file systems every 1800 seconds (or 30 minutes) could be more optimal. By not unmounting the file systems every 5 minutes, it is possible that /etc/mnttab, which is checked by df, can become large. The output from df can be filtered by using the -F option (see the df(1M) man page) or by using egrep to help fix this problem.

Another factor to consider is that adjusting the duration also changes how quickly changes to the automounter maps will be reflected. Changes will not be seen until the file system is unmounted. Refer to "Modifying the Maps" for instructions on how to modify automounter maps.


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

Caution - Caution -

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.


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

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

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

Caution - Caution -

The version of the mount command included in any Solaris release from 2.6 to the current release, will not warn about options that are not valid. 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.

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.


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 can do other processing while waiting for the mount request to complete.


This option improves performance of sequential reads on large files. Data is copied directly to a user buffer and no caching is done in the kernel on the client. This option is off by default.


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. Starting with release 2.6, by default, all 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.


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 are rejected with an error.


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


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.


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

Table 31-2 NFS Security Modes


Authentication Service Selected 


Kerberos Version 5 


No authentication 


Diffie-Hellman (DH) authentication 


Standard UNIX authentication 


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

Note -

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

Here is an example of using an NFS URL with the mount command:

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

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


This command enables you to remove a remote file system that is currently mounted. The umount command supports the -V option to allow for testing. You might also use the -a option to umount several file systems at one time. If mount_points are included with the -a option, those file systems are unmounted. If no mount points are included, an attempt is made to unmount all file systems 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 cannot 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 is busy until the working directory is changed. The umount command can 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

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


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


Use this command to unmount a group of file systems. The -k option runs the fuser -k mount_point command 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


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 does 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 already being shared. For example, if /usr and /usr/local are on one disk slice, /usr can be shared or /usr/local can be shared, but if both need to be shared with different share options, /usr/local must to be moved to a separate disk slice.

Note -

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.

Non-file System Specific share Options

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


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


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

NFS Specific share Options

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


This option enables an NFS server supporting the NFS version 2 protocol to be configured to do access control for NFS version 2 clients. Without this option all clients are given minimal access. With this option the clients have maximal access. For instance, on file systems shared with the -aclok option, if anyone has read permissions, everyone does. However, without this option, you can deny access to a client who should have access permissions. Whether it is preferred to permit too much access or too little, depends on the security systems already in place. See "Securing Files (Tasks)" in System Administration Guide, Volume 2 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, clients get correct access, but cannot manipulate the ACLs. If the software supports the NFS_ACL protocol, the clients get correct access and can manipulate the ACLs. Starting with release 2.5, the Solaris system supports both protocols.


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.


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


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


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


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


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

Caution - Caution -

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


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 use each security mode only once per command line. Each -mode option applies to any subsequent -rw, -ro, -rw=, -ro=, -root=, and -window= options, until another -mode is encountered. Using -sec=none maps all users to user nobody.


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 Solaris 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. Starting with the Solaris 2.6 release, the access list can also include a domain name, a subnet number, or an entry to deny access. These extensions should 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

Note -

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, because 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 can mount the file system read-write if they use Diffie-Hellman authentication. With these options, tulip and lilaccan 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 allows mount access to all hosts in the domain:

# share -F nfs -o /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 "" 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 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=@ /export/share/man

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

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

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

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

You can also select negative access by placing a "-" before the entry. Because the entries are read from left to right, you must place the negative access entries before the entry they apply to:

# share -F nfs -o /export/share/man

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


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 reenter run level 3. You must remove the entry for this file system from the dfstab file if the change is to continue.

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

Using the unshare Command

This command unshares a specific file system:

# unshare /usr/src


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

Using the shareall Command

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

# shareall /etc/dfs/special_dfstab


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


This command displays all 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 of all the remote mounts (each entry includes the client name and the directory), -d prints a list of the directories that are remotely mounted by clients, -e prints a list of the files shared (or exported), and hostname selects the NFS server to gather the information from. If hostname is not specified the local host is queried.

Using the showmount Command

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

# showmount -a bee

This command lists the directories that have been mounted.

# showmount -d bee

This command lists file systems that have been shared.

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


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 runs automatically when a system is booted.