Chapter 14

Managing Network File Systems (Overview)

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

NFS Terminology

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 16, Accessing Remote File Systems Reference.

NFS Servers and Clients

The terms client and server are used to describe the roles that a computer assumes when sharing file systems. If a file system resides on a computer's disk and that computer makes the file system available to other computers on the network, that computer acts as a server. The computers that are accessing that file system are said to be clients. The NFS service enables any computer to access any other computer's file systems, and at the same time, to provide access to its own file systems. A computer can assume the role of client, server, or both 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, it 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 and 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, it can be accessed from a client. You can mount an NFS file system automatically with autofs. See "Automatic File-System Sharing" and "Autofs Administration Task Overview" for tasks that involve the share command and autofs.

NFS File Systems

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

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

About the NFS Service

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

The NFS environment can be implemented on different operating systems because it 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 they are accessing a local file.

The benefits of the NFS service are that it does the following:

Enables multiple computers to use the same files, so everyone on the network can access the same data
Reduces storage costs by having computers share applications instead of needing local disk space for each user application
Provides data consistency and reliability because all users can read the same set of files
Makes mounting of file systems transparent to users
Makes accessing 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 and have all other systems access it across the network. Under NFS operation, remote file systems are almost indistinguishable from local file systems.

About Autofs

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

Whenever a user on a client computer that is running automountd tries to access a remote file or directory, the daemon mounts the file system to which that file or directory belongs. This remote file system remains mounted for as long as it is needed. If the remote file system is not accessed for a certain period of time, it 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.

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

Features of the NFS Service

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

NFS Version 2 Protocol

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

NFS Version 3 Protocol

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

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

All 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. Specifically, version 2 generated a message that reported a "write error" or a "read error" if users tried to copy a remote file to which they did not have 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 removes the 8-Kbyte transfer size limit. Clients and servers negotiate whatever transfer size they support, rather than conform to the 8-Kbyte limit imposed in version 2. The Solaris 2.5 implementation defaults to a 32-Kbyte transfer size.

NFS ACL Support

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

NFS Over TCP

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

Network Lock Manager and NFS

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

NFS Large File Support

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


	Chapter 14 Managing Network File Systems (Overview) This chapter provides an overview of the NFS service, which can be used to access file systems over the network. The chapter includes a discussion of the concepts necessary to understand the NFS service and a description of the latest features in NFS and autofs. "NFS Terminology" "About the NFS Service" "About Autofs" "Features of the NFS Service" NFS Terminology This section presents some of the basic terminology that must be understood to work with the NFS service. Expanded coverage of the NFS service is included in Chapter 16, Accessing Remote File Systems Reference. NFS Servers and Clients The terms client and server are used to describe the roles that a computer assumes when sharing file systems. If a file system resides on a computer's disk and that computer makes the file system available to other computers on the network, that computer acts as a server. The computers that are accessing that file system are said to be clients. The NFS service enables any computer to access any other computer's file systems, and at the same time, to provide access to its own file systems. A computer can assume the role of client, server, or both 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, it 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 and 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, it can be accessed from a client. You can mount an NFS file system automatically with autofs. See "Automatic File-System Sharing" and "Autofs Administration Task Overview" for tasks that involve the `share` command and autofs. NFS File Systems The objects that can be shared with the NFS service include any whole or partial directory tree or a file hierarchy--including a single file. A computer cannot share a file hierarchy that overlaps a file hierarchy that is already shared. Peripheral devices such as modems and printers cannot be shared. In most UNIX system environments, a file hierarchy that can be shared corresponds to a file system or to a portion of a file system. However, NFS support works across operating systems, and the concept of a file system might be meaningless in other, non-UNIX environments. Therefore, the term file system that is used throughout this guide refers to a file or file hierarchy that can be shared and mounted with NFS. About the NFS Service The NFS service enables computers of different architectures that run different operating systems to share file systems across a network. NFS support has been implemented on many platforms that range from the MS-DOS to the VMS operating systems. The NFS environment can be implemented on different operating systems because it 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 they are accessing a local file. The benefits of the NFS service are that it does the following: Enables multiple computers to use the same files, so everyone on the network can access the same data Reduces storage costs by having computers share applications instead of needing local disk space for each user application Provides data consistency and reliability because all users can read the same set of files Makes mounting of file systems transparent to users Makes accessing 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 and have all other systems access it across the network. Under NFS operation, remote file systems are almost indistinguishable from local file systems. About Autofs File systems that are shared through the NFS service can be mounted by using automatic mounting. Autofs, a client-side service, is a file system structure that provides automatic mounting. The autofs file system is initialized by `automount`, which is run automatically when a system is booted. The automount daemon, `automountd`, runs continuously, mounting and unmounting remote directories as necessary. Whenever a user on a client computer that is running `automountd` tries to access a remote file or directory, the daemon mounts the file system to which that file or directory belongs. This remote file system remains mounted for as long as it is needed. If the remote file system is not accessed for a certain period of time, it 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. "Autofs Administration Task Overview" and "How Autofs Works" give more specific information about the autofs service. Features of the NFS Service This section covers the important features that are included in the NFS service. NFS Version 2 Protocol Version 2 was the first version of the NFS protocol in wide use. Version 2 continues to be available on a large variety of platforms. All Solaris releases support version 2 of the NFS protocol, but Solaris releases prior to Solaris 2.5 support version 2 only. NFS Version 3 Protocol An implementation of NFS version 3 protocol was a new feature of the Solaris 2.5 release. Several changes have been made to improve interoperability and performance. For optimal use, the version 3 protocol must be running on both the NFS servers and clients. This version enables safe asynchronous writes on the server, which improve performance by allowing the server to cache client write requests in memory. The client does not need to wait for the server to commit the changes to disk, so the response time is faster. Also, the server can batch the requests, which improves the response time on the server. All 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. Specifically, version 2 generated a message that reported a "write error" or a "read error" if users tried to copy a remote file to which they did not have 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 removes the 8-Kbyte transfer size limit. Clients and servers negotiate whatever transfer size they support, rather than conform to the 8-Kbyte limit imposed in version 2. The Solaris 2.5 implementation defaults to a 32-Kbyte transfer size. NFS ACL Support Access control list (ACL) support was added in the Solaris 2.5 release. ACLs provide a finer-grained mechanism to set file access permissions than is available through standard UNIX file permissions. NFS ACL support provides a method of changing and viewing ACL entries from a Solaris NFS client to a Solaris NFS server. See "Using Access Control Lists (ACLs)" in System Administration Guide: Security Services for more information about ACLs. NFS Over TCP The default transport protocol for the NFS protocol was changed to the Transport Control Protocol (TCP) in the Solaris 2.5 release. TCP helps performance on slow networks and wide area networks. TCP also provides congestion control and error recovery. NFS over TCP works with version 2 and version 3. Prior to 2.5, the default NFS protocol was User Datagram Protocol (UDP). Network Lock Manager and NFS The Solaris 2.5 release also included an improved version of the network lock manager, which provided UNIX record locking and PC file sharing for NFS files. The locking mechanism is now more reliable for NFS files, so commands which use locking are less likely to hang. NFS Large File Support The Solaris 2.6 implementation of the NFS version 3 protocol was changed to correctly manipulate files larger than 2 Gbytes. The NFS version 2 protocol and the Solaris 2.5 implementation of the version 3 protocol cannot handle files larger than 2 Gbytes.