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.
