Chapter 9. Network File System (NFS)
NFS (Network File System) allows hosts to mount partitions on a remote system and use them as though they are local file systems. This allows the system administrator to store resources in a central location on the network, providing authorized users continuous access to them.
Two versions of NFS are currently in use. NFS version 2 (NFSv2), which has been around for several years, is widely supported by various operating systems. NFS version 3 (NFSv3) has several more features, including a variable file handle size and better error reporting. Red Hat Linux supports both NFSv2 and NFSv3, and uses NFSv3 by default when connecting with a server that supports it.
This chapter will focus on NFS version 2, though many of the concepts discussed also apply to version 3. Additionally, only fundamental NFS concepts and supplemental information will be provided. For specific instructions regarding the configuration and operation of NFS on client or server machines, see the chapter titled Network File System (NFS) in the Red Hat Linux Customization Guide.
9.1. Methodology
Linux uses a combination of kernel-level support and continuously running daemon processes to provide NFS file sharing, however, NFS support must be enabled in the Linux kernel in order to function. NFS uses Remote Procedure Calls (RPC) to route requests between clients and servers, meaning that the portmap service must be enabled and active at the proper runlevels for NFS communication to occur. Working with portmap, the following processes ensure that a given NFS connection is allowed and may proceed without error:
rpc.mountd — The running process that receives the mount request from an NFS client and checks to see if it matches with a currently exported file system.
rpc.nfsd — The process that implements the user-space components of the NFS service. It works with the Linux kernel to meet the dynamic demands of NFS clients, such as providing additional server threads for NFS clients to use.
rpc.lockd — A daemon that is not necessary with modern kernels. NFS file locking is now done by the kernel. It is included with the nfs-utils package for users of older kernels that do not include this functionality by default.
rpc.statd — Implements the Network Status Monitor (NSM) RPC protocol. This provides reboot notification when an NFS server is restarted without being gracefully brought down.
rpc.rquotad — An RPC server that provides user quota information for remote users.
Not all of these programs are required for NFS service. The only services that must be enabled are rpc.mountd, rpc.nfsd, and portmap. The other daemons provide additional functionality and should only be used if the server environment requires them.
NFS version 2 uses the User Datagram Protocol (UDP) to provide a stateless network connection between the client and server. NFS version 3 can use UDP or TCP running over an IP. The stateless UDP connection minimizes network traffic, as the NFS server sends the client a cookie after the client is authorized to access the shared volume. This cookie is a random value stored on the server's side and is passed along with RPC requests from the client. The NFS server can be restarted without affecting the clients and the cookie will remain intact.
NFS only performs authentication when a client system attempts to mount a remote file system. To limit access, the NFS server first employs TCP wrappers. TCP wrappers reads the /etc/hosts.allow and /etc/hosts.deny files to determine if a particular client should be permitted or prevented access to the NFS server. For more information on configuring access controls with TCP wrappers, see Chapter 15 TCP Wrappers and xinetd.
After the client is granted access by TCP wrappers, the NFS server refers to its configuration file, /etc/exports, to determine whether the client can mount any of the exported file systems. After granting access, any file and directory operations are sent to the server using remote procedure calls.
 | Warning |
|---|---|
NFS mount privileges are granted specifically to a client, not a user. Exported file systems can be a accessed by any users on the remote machine. When configuring the /etc/exports file, be very careful when granting read-write permissions (rw) for an exported file system. |
9.1.1. NFS and portmap
NFS relies upon remote procedure calls (RPC) to function. The portmap service is required to map RPC requests to the correct services. RPC processes notify portmap when they start, revealing the port number they are monitoring and the RPC program numbers they expect to serve. The client system then contacts portmap on the server with a particular RPC program number. portmap then redirects the client to the proper port number to communicate with its intended service.
Because RPC-based services rely on portmap to make all connections with incoming client requests, portmap must be available before any of these services start. If, for some reason, the portmap service unexpectedly quits, restart portmap and any services running when it was started.
The portmap service can be used with TCP wrappers' hosts access files (/etc/hosts.allow and /etc/hosts.deny) to control which remote systems are permitted to use RPC-based services on the server. See Chapter 15 TCP Wrappers and xinetd for more information. Access control rules for portmap will affect all RPC-based services. Alternatively, it is possible to specify each of the NFS RPC daemons to be affected by a particular access control rule. The man pages for rpc.mountd and rpc.statd contain information regarding the precise syntax for these rules.
9.1.1.1. Trouble shooting NFS with portmap
As portmap provides the coordination between RPC services and the port numbers used to communicate with them, it is useful to be able to view the status of current RPC services using portmap when troubleshooting. The rpcinfo command shows each RPC-based service with its port number, RPC program number, version, and IP protocol type (TCP or UDP).
To make sure the proper NFS RPC-based services are enabled for portmap, use the rpcinfo -p command:
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100024 1 udp 1024 status
100024 1 tcp 1024 status
100011 1 udp 819 rquotad
100011 2 udp 819 rquotad
100005 1 udp 1027 mountd
100005 1 tcp 1106 mountd
100005 2 udp 1027 mountd
100005 2 tcp 1106 mountd
100005 3 udp 1027 mountd
100005 3 tcp 1106 mountd
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100021 1 udp 1028 nlockmgr
100021 3 udp 1028 nlockmgr
100021 4 udp 1028 nlockmgr |
The -p option probes the portmapper on the specified host or defaults to localhost if no specific host is listed. Other options are available from the rpcinfo man page.
From this output, it is apparent that various NFS services are running. If one of the NFS services does not start up correctly, portmap will be unable to map RPC requests from clients for that service to the correct port. In many cases, restarting NFS as root (/sbin/service nfs restart) will cause those service to correctly register with portmap and begin working.