Chapter 21. 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.
21.1. How It Works
Currently, there are three versions of NFS. NFS version 2 (NFSv2) is older and is widely supported. NFS version 3 (NFSv3) has more features, including 64bit file handles, Safe Async writes and more robust error handling. NFS version 4 (NFSv4) works through firewalls and on the Internet, no longer requires portmapper, supports ACLs, and utilizes stateful operations. Red Hat Enterprise Linux supports NFSv2, NFSv3, and NFSv4 clients, and when mounting a file system via NFS, Red Hat Enterprise Linux uses NFSv3 by default, if the server supports it.
All versions of NFS can use Transmission Control Protocol (TCP) running over an IP network, with NFSv4 requiring it. NFSv2 and NFSv3 can use the User Datagram Protocol (UDP) running over an IP network to provide a stateless network connection between the client and server.
When using NFSv2 or NFSv3 with UDP, the stateless UDP connection under normal conditions has less Protocol overhead than TCP which can translate into better performance on very clean, non-congested networks. The NFS server sends the client a file handle after the client is authorized to access the shared volume. This file handle is an opaque object 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 NFS server.
Because protocol support has been incorporated into the v4 protocol, NFSv4 has no interaction with the
rpc.statddaemons. NFSv4 listens on the well-known TCP port 2049, which eliminates the need for
portmapinteraction. The mounting and locking protocols have been incorporated into the V4 protocol which eliminates the need for interaction with
rpc.mountddaemon is still required on the server, but is not involved in any over-the-wire operations.
TCP is the default transport protocol for NFS under Red Hat Enterprise Linux. UDP can be used for compatibility purposes as needed, but is not recommended for wide usage.
All the RPC/NFS daemon have a
-pcommand line option that can set the port, making firewall configuration easier.
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.
In order for NFS to work with a default installation of Red Hat Enterprise Linux with a firewall enabled, IPTables with the default TCP port 2049 must be configured. Without proper IPTables configuration, NFS does not function properly.
The NFS initialization script and
rpc.nfsdprocess now allow binding to any specified port during system start up. However, this can be error prone if the port is unavailable or conflicts with another daemon.
21.1.1. Required Services
Red Hat Enterprise Linux uses a combination of kernel-level support and daemon processes to provide NFS file sharing. All NFS versions rely on Remote Procedure Calls (RPC) between clients and servers. RPC services under Linux are controlled by the
portmapservice. To share or mount NFS file systems, the following services work together, depending on which version of NFS is implemented:
/sbin/service nfs start) starts the NFS server and the appropriate RPC processes to service requests for shared NFS file systems.
/sbin/service nfslock start) is a mandatory service that starts the appropriate RPC processes to allow NFS clients to lock files on the server.
portmap— accepts port reservations from local RPC services. These ports are then made available (or advertised) so the corresponding remote RPC services access them.
portmapresponds to requests for RPC services and sets up connections to the requested RPC service.
The following RPC processes 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
nfsservice and does not require user configuration.
rpc.nfsd— Allows explicit NFS versions and protocols the server advertises to be defined. 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
rpc.lockd— allows NFS clients to lock files on the server. If
rpc.lockdis not started, file locking will fail.
rpc.lockdimplements the Network Lock Manager (NLM) protocol. This process corresponds to the
nfslockservice. This is not used with NFSv4.
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
nfslockservice and does not require user configuration. This is not used with NFSv4.
rpc.rquotad— This process provides user quota information for remote users. This process is started automatically by the
nfsservice and does not require user configuration.
rpc.idmapd— This process provides NFSv4 client and server upcalls which map between on-the-wire NFSv4 names (which are strings in the form of user@domain) and local UIDs and GIDs. For
idmapdto function with NFSv4, the
/etc/idmapd.confmust be configured. This service is required for use with NFSv4.
To use NFS on your system, make sure you have the nfs-utils, nfs-utils-lib, and portmap packages installed.