Chapter 9. Network File System (NFS)
9.1. How NFS Works
rpcbindservice, supports ACLs, and utilizes stateful operations. Red Hat Enterprise Linux 6 supports NFSv2, NFSv3, and NFSv4 clients. When mounting a file system via NFS, Red Hat Enterprise Linux uses NFSv4 by default, if the server supports it.
rpc.mountddaemon is required on the NFS server to set up the exports.
'-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.
9.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 6 to enable IPv6 support.
service nfs startstarts the NFS server and the appropriate RPC processes to service requests for shared NFS file systems.
service nfslock startactivates 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.
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
NoteAs of Red Hat Enterprise Linux 6.3, 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.
- This process is used by an NFS server to process
MOUNTrequests from NFSv2 and 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.
lockdis a kernel thread which runs on both clients and servers. It implements the Network Lock Manager (NLM) protocol, which allows NFSv2 and 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.