Chapter 8. Network File System (NFS)
8.1. Introduction to NFS
- NFS version 3 (NFSv3) supports safe asynchronous writes and is more robust at error handling than the previous NFSv2; it also supports 64-bit file sizes and offsets, allowing clients to access more than 2 GB of file data.
- NFS version 4 (NFSv4) works through firewalls and on the Internet, no longer requires an
rpcbindservice, supports ACLs, and utilizes stateful operations.
- Enhances performance and security of network, and also includes client-side support for Parallel NFS (pNFS).
- No longer requires a separate TCP connection for callbacks, which allows an NFS server to grant delegations even when it cannot contact the client. For example, when NAT or a firewall interferes.
- It provides once semantics (except for reboot operations), preventing a previous issue whereby certain operations could return an inaccurate result if a reply was lost and the operation was sent twice.
rpc.mountddaemon is still required on the NFS server to set up the exports, but is not involved in any over-the-wire operations.
'-p'command line option that can set the port, making firewall configuration easier.
/etc/exportsconfiguration file to determine whether the client is allowed to access any exported file systems. Once verified, all file and directory operations are available to the user.
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 if it conflicts with another daemon.
8.1.1. Required Services
rpcbindservice. To share or mount NFS file systems, the following services work together depending on which version of NFS is implemented:
portmapservice was used to map RPC program numbers to IP address port number combinations in earlier versions of Red Hat Enterprise Linux. This service is now replaced by
rpcbindin Red Hat Enterprise Linux 7 to enable IPv6 support.
systemctl start nfsstarts the NFS server and the appropriate RPC processes to service requests for shared NFS file systems.
systemctl start nfs-lockactivates a mandatory service that starts the appropriate RPC processes allowing NFS clients to lock files on the server.
rpcbindaccepts port reservations from local RPC services. These ports are then made available (or advertised) so the corresponding remote RPC services can access them.
rpcbindresponds to requests for RPC services and sets up connections to the requested RPC service. This is not used with NFSv4.
- This process is used by an NFS server to process
MOUNTrequests from NFSv3 clients. It checks that the requested NFS share is currently exported by the NFS server, and that the client is allowed to access it. If the mount request is allowed, the rpc.mountd server replies with a
Successstatus and provides the
File-Handlefor this NFS share back to the NFS client.
rpc.nfsdallows 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
lockdis a kernel thread which runs on both clients and servers. It implements the Network Lock Manager (NLM) protocol, which allows NFSv3 clients to lock files on the server. It is started automatically whenever the NFS server is run and whenever an NFS file system is mounted.
- 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.
rpc.statdis started automatically by the
nfslockservice, and does not require user configuration. This is not used with NFSv4.
- This process provides user quota information for remote users.
rpc.rquotadis started automatically by the
nfsservice and does not require user configuration.
rpc.idmapdprovides NFSv4 client and server upcalls, which map between on-the-wire NFSv4 names (strings in the form of
user@domain) and local UIDs and GIDs. For
idmapdto function with NFSv4, the
/etc/idmapd.conffile must be configured. At a minimum, the "Domain" parameter should be specified, which defines the NFSv4 mapping domain. If the NFSv4 mapping domain is the same as the DNS domain name, this parameter can be skipped. The client and server must agree on the NFSv4 mapping domain for ID mapping to function properly.
NoteIn Red Hat Enterprise Linux 7, only the NFSv4 server uses
rpc.idmapd. The NFSv4 client uses the keyring-based idmapper
nfsidmapis a stand-alone program that is called by the kernel on-demand to perform ID mapping; it is not a daemon. If there is a problem with
nfsidmapdoes the client fall back to using
rpc.idmapd. More information regarding
nfsidmapcan be found on the nfsidmap man page.