Chapter 9. Network File System (NFS)
A Network File System (NFS) allows remote hosts to mount file systems over a network and interact with those file systems as though they are mounted locally. This enables system administrators to consolidate resources onto centralized servers on the network.
This chapter focuses on fundamental NFS concepts and supplemental information. For specific instructions regarding the configuration and operation of NFS server and client software, refer to the chapter titled Network File System (NFS) in the Red Hat Enterprise Linux System Administration Guide.
9.1. How It Works
Currently, there are two versions of NFS. NFS version 2 (NFSv2) is older and is widely supported. NFS version 3 (NFSv3) has more features, including variable size file handling and better error reporting, but is not fully compatible with NFSv2 clients. Red Hat Enterprise Linux serves both NFSv2 and NFSv3 clients, and when mounting a file system via NFS, Red Hat Enterprise Linux uses NFSv3 by default, if server the supports it.
NFSv2 uses the User Datagram Protocol (UDP) to provide a stateless network connection between the client and server. NFSv3 can use either UDP or Transmission Control Protocol (TCP) running over an IP network.
The stateless UDP connection under normal conditions 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 remains intact. However, because UDP is stateless, if the server goes down unexpectedly, UDP clients continue to saturate the network with requests for the server. For this reason, TCP is the preferred protocol when connecting to an NFSv3 server.
 | Note |
|---|---|
For compatibility purposes, UDP is the default transport protocol for NFS under Red Hat Enterprise Linux. Refer to the chapter titled Network File System (NFS) in the Red Hat Enterprise Linux System Administration Guide for more information about connecting to NFS servers using TCP. |
The only time NFS performs authentication is when a client system attempts to mount the shared NFS resource. To limit access to the NFS service, TCP wrappers are used. TCP wrappers read the /etc/hosts.allow and /etc/hosts.deny files to determine if a particular client or network is permitted or denied access to the NFS service. For more information on configuring access controls with TCP wrappers, refer to Chapter 16 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 is allowed to access any of the exported file systems. Once access is granted, all file and directory operations are available to the user.
 | Warning |
|---|---|
NFS mount privileges are granted to the client host, not the user. Therefore, exported file systems can be accessed by any user on a client host with access permissions. When configuring the NFS shares, be very careful which hosts get read/write permissions (rw). |
9.1.1. Required Services
Red Hat Enterprise Linux uses a combination of kernel-level support and daemon processes to provide NFS file sharing. NFS relies on Remote Procedure Calls (RPC) to route requests between clients and servers . RPC services under Linux are controlled by the portmap service. To share or mount NFS file systems, the following services work together:
nfs — Starts the appropriate RPC processes to service requests for shared NFS file systems.
nfslock — An optional service that starts the appropriate RPC processes to allow NFS clients to lock files on the server.
portmap — The RPC service for Linux; it responds to requests for RPC services and sets up connections to the requested RPC service.
The following RPC processes work together behind the scenes to facilitate NFS services:
rpc.mountd — This process receives mount requests from NFS clients and verifies the requested file system is currently exported. This process is started automatically by the nfs service and does not require user configuration.
rpc.nfsd — This process is the NFS server. It works with the Linux kernel to meet the dynamic demands of NFS clients, such as providing server threads each time an NFS client connects. This process corresponds to the nfs service.
rpc.lockd — An optional process that allows NFS clients to lock files on the server. This process corresponds to the nfslock service.
rpc.statd — This process implements the Network Status Monitor (NSM) RPC protocol which notifies NFS clients when an NFS server is restarted without being gracefully brought down. This process is started automatically by the nfslock service and does not require user configuration.
rpc.rquotad — This process provides user quota information for remote users. This process is started automatically by the nfs service and does not require user configuration.
9.1.2. NFS and portmap
The portmap service under Linux maps 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. The portmap service redirects the client to the proper port number so it can communicate with the requested 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.
The portmap service uses TCP wrappers for access control, and access control rules for portmap affect all RPC-based services. Alternatively, it is possible to specify access control rules for each of the NFS RPC daemons. The man pages for rpc.mountd and rpc.statd contain information regarding the precise syntax for these rules.
9.1.2.1. Troubleshooting NFS and portmap
Because portmap provides coordination between RPC services and the port numbers used to communicate with them, it is useful to view the status of current RPC services using portmap when troubleshooting. The rpcinfo command shows each RPC-based service with port numbers, an RPC program number, a version and an IP protocol type (TCP or UDP).
To make sure the proper NFS RPC-based services are enabled for portmap, issue the following command as root:
rpcinfo -p |
The following is sample output from this command:
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100021 1 udp 32774 nlockmgr
100021 3 udp 32774 nlockmgr
100021 4 udp 32774 nlockmgr
100021 1 tcp 34437 nlockmgr
100021 3 tcp 34437 nlockmgr
100021 4 tcp 34437 nlockmgr
100011 1 udp 819 rquotad
100011 2 udp 819 rquotad
100011 1 tcp 822 rquotad
100011 2 tcp 822 rquotad
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
100005 1 udp 836 mountd
100005 1 tcp 839 mountd
100005 2 udp 836 mountd
100005 2 tcp 839 mountd
100005 3 udp 836 mountd
100005 3 tcp 839 mountd |
The output from this command reveals that the correct NFS services are running. If one of the NFS services does not start up correctly, portmap is unable to map RPC requests from clients for that service to the correct port. In many cases, if NFS is not present in rpcinfo output, restarting NFS causes the service to correctly register with portmap and begin working. For instructions on starting NFS, refer to Section 9.2 Starting and Stopping NFS.
Other useful options are available for the rpcinfo command. Refer to the rpcinfo man page for more information.