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.
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 variable size file handling and better error reporting, but is
not fully compatible with NFSv2 clients. NFS version 4 (NFSv4) includes
Kerberos security, 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 NFSv4 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 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 NFS server.
When using NFSv4, a stateful connection is made, and Kerberos user and
group authentication with various security levels is optionally
available. NFSv4 has no interaction with portmapper,
rpc.mountd, rpc.lockd, and
rpc.statd, since they have been rolled
into the kernel. NFSv4 listens on the well known TCP port 2049.
 | Note |
|---|
| | TCP 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. UDP can be used for compatibility
purposes as needed, but is not recommended for wide usage.
|
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 17 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 |
|---|
| | If using NFSv2 or NFSv3, which do not support Kerberos
authentication, 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).
|
 | Important |
|---|
| | 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 an IPTables configuration, NFS does not function
properly.
The NFS initialization script and rpc.nfsd process
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.
|
Red Hat Enterprise Linux uses a combination of kernel-level support and daemon processes
to provide NFS file sharing. NFSv2 and NFSv3 rely on Remote
Procedure Calls (RPC) to encode and decode
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,
depending on which version of NFS is implemented:
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. This is not used with NFSv4.
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 nfs service
and does not require user configuration. This is not used with NFSv4.
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. 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 nfslock service 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 nfs service 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 idmapd to function
with NFSv4, the /etc/idmapd.conf must be
configured. This service is required for use with NFSv4.
rpc.svcgssd — This process provides
the server transport mechanism for the authentication process
(Kerberos Version 5) with NFSv4. This service is required for use
with NFSv4.
rpc.gssd — This process provides the
client transport mechanism for the authentication process
(Kerberos Version 5) with NFSv4. This service is required for use
with NFSv4.
| Note |
|---|
| | The following section only applies to NFSv2 or NFSv3 implementations
that require the portmap service for backward
compatibility.
|
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.
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 number, 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:
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.
