This chapter provides an overview of the NFS service, which can be used to access file systems over the network. The chapter includes a discussion of the concepts necessary to understand the NFS service and a description of the latest features in NFS and autofs.
If your system has zones enabled and you want to use this feature in a non-global zone, see System Administration Guide: Oracle Solaris Containers-Resource Management and Oracle Solaris Zones for more information.
This section provides information about new features in releases of the Solaris OS.
The Solaris 10 11/06 release provides support for a file system monitoring tool. See the following:
Additionally, this Guide provides a more detailed description of the nfsmapid daemon. For information about nfsmapid, see the following:
For a complete list of new features, see Oracle Solaris 10 9/10 What’s New.
Starting in the Solaris 10 release, NFS version 4 is the default. For information about features in NFS version 4 and other changes, refer to the following:
Also, see the following:
Setting Up NFS Services for task information
Oracle Solaris 10 9/10 What’s New for a complete list of new features
Additionally, the NFS service is managed by the Service Management Facility. Administrative actions on this service, such as enabling, disabling, or restarting, can be performed by using the svcadm command. The service's status can be queried by using the svcs command. For more information about the Service Management Facility, refer to the smf(5) man page and Chapter 18, Managing Services (Overview), in System Administration Guide: Basic Administration.
This section presents some of the basic terminology that must be understood to work with the NFS service. Expanded coverage of the NFS service is included in Chapter 6, Accessing Network File Systems (Reference).
The terms client and server are used to describe the roles that a computer assumes when sharing file systems. Computers that share their file systems over a network are acting as servers. The computers that are accessing the file systems are said to be clients. The NFS service enables any computer to access any other computer's file systems. At the same time, the NFS service provides access to its own file systems. A computer can assume the role of client, server, or both client and server at any particular time on a network.
Clients access files on the server by mounting the server's shared file systems. When a client mounts a remote file system, the client does not make a copy of the file system. Rather, the mounting process uses a series of remote procedure calls that enable the client to access the file system transparently on the server's disk. The mount resembles a local mount. Users type commands as if the file systems were local. See Mounting File Systems for information about tasks that mount file systems.
After a file system has been shared on a server through an NFS operation, the file system can be accessed from a client. You can mount an NFS file system automatically with autofs. See Automatic File System Sharing and Task Overview for Autofs Administration for tasks that involve the share command and autofs.
The objects that can be shared with the NFS service include any whole or partial directory tree or a file hierarchy, including a single file. A computer cannot share a file hierarchy that overlaps a file hierarchy that is already shared. Peripheral devices such as modems and printers cannot be shared.
In most UNIX system environments, a file hierarchy that can be shared corresponds to a file system or to a portion of a file system. However, NFS support works across operating systems, and the concept of a file system might be meaningless in other, non-UNIX environments. Therefore, the term file system refers to a file or file hierarchy that can be shared and be mounted with NFS.
The NFS service enables computers of different architectures that run different operating systems to share file systems across a network. NFS support has been implemented on many platforms that range from the MS-DOS to the VMS operating systems.
The NFS environment can be implemented on different operating systems because NFS defines an abstract model of a file system, rather than an architectural specification. Each operating system applies the NFS model to its file-system semantics. This model means that file system operations such as reading and writing function as though the operations are accessing a local file.
The NFS service has the following benefits:
Enables multiple computers to use the same files so that everyone on the network can access the same data
Reduces storage costs by having computers share applications instead of needing local disk space for each user application
Provides data consistency and reliability because all users can read the same set of files
Makes mounting of file systems transparent to users
Makes accessing of remote files transparent to users
Supports heterogeneous environments
Reduces system administration overhead
The NFS service makes the physical location of the file system irrelevant to the user. You can use the NFS implementation to enable users to see all the relevant files regardless of location. Instead of placing copies of commonly used files on every system, the NFS service enables you to place one copy on one computer's disk. All other systems access the files across the network. Under NFS operation, remote file systems are almost indistinguishable from local file systems.
File systems that are shared through the NFS service can be mounted by using automatic mounting. Autofs, a client-side service, is a file-system structure that provides automatic mounting. The autofs file system is initialized by automount, which is run automatically when a system is booted. The automount daemon, automountd, runs continuously, mounting and unmounting remote directories as necessary.
Whenever a client computer that is running automountd tries to access a remote file or remote directory, the daemon mounts the remote file system. This remote file system remains mounted for as long as needed. If the remote file system is not accessed for a certain period of time, the file system is automatically unmounted.
Mounting need not be done at boot time, and the user no longer has to know the superuser password to mount a directory. Users do not need to use the mount and umount commands. The autofs service mounts and unmounts file systems as required without any intervention by the user.
Mounting some file hierarchies with automountd does not exclude the possibility of mounting other hierarchies with mount. A diskless computer must mount / (root), /usr, and /usr/kvm through the mount command and the /etc/vfstab file.
This section describes the important features that are included in the NFS service.
Version 2 was the first version of the NFS protocol in wide use. Version 2 continues to be available on a large variety of platforms. All Solaris releases support version 2 of the NFS protocol, but Solaris releases prior to Solaris 2.5 support version 2 only.
An implementation of NFS version 3 protocol was a new feature of the Solaris 2.5 release. Several changes have been made to improve interoperability and performance. For optimal use, the version 3 protocol must be running on both the NFS servers and clients.
Unlike the NFS version 2 protocol, the NFS version 3 protocol can handle files that are larger than 2 Gbytes. The previous limitation has been removed. See NFS Large File Support.
The NFS version 3 protocol enables safe asynchronous writes on the server, which improve performance by allowing the server to cache client write requests in memory. The client does not need to wait for the server to commit the changes to disk, so the response time is faster. Also, the server can batch the requests, which improves the response time on the server.
Many Solaris NFS version 3 operations return the file attributes, which are stored in the local cache. Because the cache is updated more often, the need to do a separate operation to update this data arises less often. Therefore, the number of RPC calls to the server is reduced, improving performance.
The process for verifying file access permissions has been improved. Version 2 generated a “write error” message or a “read error” message if users tried to copy a remote file without the appropriate permissions. In version 3, the permissions are checked before the file is opened, so the error is reported as an “open error.”
The NFS version 3 protocol removed the 8-Kbyte transfer size limit. Clients and servers could negotiate whatever transfer size the clients and servers support, rather than conform to the 8-Kbyte limit that version 2 imposed. Note that in the Solaris 2.5 implementation, the protocol defaulted to a 32-Kbyte transfer size. Starting in the Solaris 10 release, restrictions on wire transfer sizes are relaxed. The transfer size is based on the capabilities of the underlying transport.
NFS version 4 has features that are not available in the previous versions.
To map these version 4 ID strings to a local numeric ID
To map the local numeric IDs to version 4 ID strings
For more information, refer to nfsmapid Daemon.
Note that in NFS version 4, the ID mapper, nfsmapid, is used to map user or group IDs in ACL entries on a server to user or group IDs in ACL entries on a client. The reverse is also true. For more information, see ACLs and nfsmapid in NFS Version 4.
With NFS version 4, when you unshare a file system, all the state for any open files or file locks in that file system is destroyed. In NFS version 3 the server maintained any locks that the clients had obtained before the file system was unshared. For more information, refer to Unsharing and Resharing a File System in NFS Version 4.
NFS version 4 servers use a pseudo file system to provide clients with access to exported objects on the server. Prior to NFS version 4 a pseudo file system did not exist. For more information, refer to File-System Namespace in NFS Version 4.
In NFS version 2 and version 3 the server returned persistent file handles. NFS version 4 supports volatile file handles. For more information, refer to Volatile File Handles in NFS Version 4.
Delegation, a technique by which the server delegates the management of a file to a client, is supported on both the client and the server. For example, the server could grant either a read delegation or a write delegation to a client. For more information, refer to Delegation in NFS Version 4.
Starting in the Solaris 10 release, NFS version 4 does not support the LIPKEY/SPKM security flavor.
Also, NFS version 4 does not use the following daemons:
For a complete list of the features in NFS version 4, refer to Features in NFS Version 4.
For procedural information that is related to using NFS version 4, refer to Setting Up NFS Services.
The /etc/default/nfs file has keywords to control the NFS protocols that are used by both the client and the server. For example, you can use keywords to manage version negotiation. For more information, refer to Keywords for the /etc/default/nfs File or the nfs(4) man page.
Access control list (ACL) support was added in the Solaris 2.5 release. ACLs provide a finer-grained mechanism to set file access permissions than is available through standard UNIX file permissions. NFS ACL support provides a method of changing and viewing ACL entries from a Solaris NFS client to a Solaris NFS server.
The NFS Version 2 and Version 3 protocols support the old POSIX-draft style ACLs. POSIX-draft ACLs are natively supported by UFS. See Using Access Control Lists to Protect UFS Files in System Administration Guide: Security Services for more information about UFS ACLs.
The NFS Version 4 protocol supports the new NFSv4 style ACLs. NFSv4 ACLs are natively supported by ZFS. For full featured NFSv4 ACL functionality, ZFS must be used as the underlying file system on the NFSv4 server. The NFSv4 ACLs have a rich set of inheritance properties, as well as a set of permission bits beyond the standard read, write and execute. See Chapter 8, Using ACLs to Protect Oracle Solaris ZFS Files, in Oracle Solaris ZFS Administration Guide for an overview of the new ACLs. For more information about support for ACLs in NFS version 4, see ACLs and nfsmapid in NFS Version 4.
The default transport protocol for the NFS protocol was changed to the Transport Control Protocol (TCP) in the Solaris 2.5 release. TCP helps performance on slow networks and wide area networks. TCP also provides congestion control and error recovery. NFS over TCP works with version 2, version 3, and version 4. Prior to the Solaris 2.5 release, the default NFS protocol was User Datagram Protocol (UDP).
Starting in the Solaris 10 release, the NFS client no longer uses an excessive number of UDP ports. Previously, NFS transfers over UDP used a separate UDP port for each outstanding request. Now, by default, the NFS client uses only one UDP reserved port. However, this support is configurable. If the use of more simultaneous ports would increase system performance through increased scalability, then the system can be configured to use more ports. This capability also mirrors the NFS over TCP support, which has had this kind of configurability since its inception. For more information, refer to the Oracle Solaris Tunable Parameters Reference Manual.
NFS version 4 does not use UDP. If you mount a file system with the proto=udp option, then NFS version 3 is used instead of version 4.
The Solaris 10 release includes the Remote Direct Memory Access (RDMA) protocol, which is a technology for memory-to-memory transfer of data over high speed networks. Specifically, RDMA provides remote data transfer directly to and from memory without CPU intervention. To provide this capability, RDMA combines the interconnect I/O technology of InfiniBand-on-SPARC platforms with the Solaris Operating System. For more information, refer to NFS Over RDMA.
The Solaris 2.5 release also included an improved version of the network lock manager. The network lock manager provided UNIX record locking and PC file sharing for NFS files. The locking mechanism is now more reliable for NFS files, so commands that use locking are less likely to hang.
The Network Lock Manager is used only for NFS version 2 and version 3 mounts. File locking is built into the NFS version 4 protocol.
The Solaris 2.6 implementation of the NFS version 3 protocol was changed to correctly manipulate files that were larger than 2 Gbytes. The NFS version 2 protocol and the Solaris 2.5 implementation of the version 3 protocol could not handle files that were larger than 2 Gbytes.
Dynamic failover of read-only file systems was added in the Solaris 2.6 release. Failover provides a high level of availability for read-only resources that are already replicated, such as man pages, other documentation, and shared binaries. Failover can occur anytime after the file system is mounted. Manual mounts can now list multiple replicas, much like the automounter in previous releases. The automounter has not changed, except that failover need not wait until the file system is remounted. See How to Use Client-Side Failover and Client-Side Failover for more information.
Support for Kerberos V4 clients was included in the Solaris 2.0 release. In the 2.6 release, the mount and share commands were altered to support NFS version 3 mounts that use Kerberos V5 authentication. Also, the share command was changed to enable multiple authentication flavors for different clients. See RPCSEC_GSS Security Flavor for more information about changes that involve security flavors. See Configuring Kerberos NFS Servers in System Administration Guide: Security Services for information about Kerberos V5 authentication.
The Solaris 2.6 release also included the ability to make a file system on the Internet accessible through firewalls. This capability was provided by using an extension to the NFS protocol. One of the advantages to using the WebNFSTM protocol for Internet access is its reliability. The service is built as an extension of the NFS version 3 and version 2 protocol. Additionally, the WebNFS implementation provides the ability to share these files without the administrative overhead of an anonymous ftp site. See Security Negotiation for the WebNFS Service for a description of more changes that are related to the WebNFS service. See WebNFS Administration Tasks for more task information.
The NFS version 4 protocol is preferred over the WebNFS service. NFS version 4 fully integrates all the security negotiation that was added to the MOUNT protocol and the WebNFS service.
A security flavor, called RPCSEC_GSS, is supported in the Solaris 7 release. This flavor uses the standard GSS-API interfaces to provide authentication, integrity, and privacy, as well as enabling support of multiple security mechanisms. See Kerberos Support for the NFS Service for more information about support of Kerberos V5 authentication. See Oracle Solaris Security for Developers Guide for more information about GSS-API.
The Solaris 7 release includes extensions to the mount command and automountd command. The extensions enable the mount request to use the public file handle instead of the MOUNT protocol. The MOUNT protocol is the same access method that the WebNFS service uses. By circumventing the MOUNT protocol, the mount can occur through a firewall. Additionally, because fewer transactions need to occur between the server and the client, the mount should occur faster.
The extensions also enable NFS URLs to be used instead of the standard path name. Also, you can use the public option with the mount command and the automounter maps to force the use of the public file handle. See WebNFS Support for more information about changes to the WebNFS service.
A new protocol has been added to enable a WebNFS client to negotiate a security mechanism with an NFS server in the Solaris 8 release. This protocol provides the ability to use secure transactions when using the WebNFS service. See How WebNFS Security Negotiation Works for more information.
In the Solaris 8 release, NFS server logging enables an NFS server to provide a record of file operations that have been performed on its file systems. The record includes information about which file was accessed, when the file was accessed, and who accessed the file. You can specify the location of the logs that contain this information through a set of configuration options. You can also use these options to select the operations that should be logged. This feature is particularly useful for sites that make anonymous FTP archives available to NFS and WebNFS clients. See How to Enable NFS Server Logging for more information.
NFS version 4 does not support server logging.
A fully multithreaded version of automountd was included in the Solaris 2.6 release. This enhancement makes autofs more reliable and enables concurrent servicing of multiple mounts, which prevents the service from hanging if a server is unavailable.
The new automountd also provides better on-demand mounting. Previous releases would mount an entire set of file systems if the file systems were hierarchically related. Now, only the top file system is mounted. Other file systems that are related to this mount point are mounted when needed.
The autofs service supports browsability of indirect maps. This support enables a user to see which directories could be mounted, without having to actually mount each file system. A -nobrowse option has been added to the autofs maps so that large file systems, such as /net and /home, are not automatically browsable. Also, you can turn off autofs browsability on each client by using the -n option with automount. See Disabling Autofs Browsability for more information.