Chapter 17. Network File System (NFS)

NFS (Network File System) exists to allow remote hosts to mount partitions on a particular system and use them as though they were local filesystems. This allows files to be organized in a central location, while providing the functionality of allowing authorized users continuous access to them.

Two versions of NFS are currently in use. NFS version 2, which has been around for several years, is widely supported by various operating systems. NFS version 3 has several more features, including a variable file handle size and better error reporting. Red Hat Linux supports both NFSv2 and NFSv3, and uses NFSv3 by default when connecting with a server which supports it.

This chapter will focus on NFS version 2, though many of the concepts discussed also apply to version 3. Additionally, only fundamental NFS concepts and supplemental information will be provided. For specific instructions regarding the configuration and operation of NFS on client or server machines, see the Official Red Hat Linux Customization Guide.

Methodology

Linux uses a combination of kernel-level support and continuously running daemon processes to provide NFS file sharing, and NFS support must be enabled in the Linux kernel to function. NFS uses Remote Procedure Calls (RPC) to route requests between clients and servers, meaning that the portmap service must be enabled and active at the proper runlevels for NFS communication to occur. Working with portmap, various other processes ensure that a particular NFS connection is allowed and may proceed without error:

Not all of these programs are required for NFS service. The only services that must be enabled are rpc.mountd, rpc.nfsd, and portmap. The other daemons provide additional functionality, based on the particular requirements of your server environment.

NFS version 2 uses the User Datagram Protocol (UDP) to provide a stateless network connection between the client and server. (NFS version 3 can use UDP or TCP running over an IP.) The stateless UDP connection minimizes network traffic, as the NFS server sends the client a cookie after the client is authorized to access the shared volume. This cookie, or random value that is stored on the server's side, is passed with any RPC requests from the client to the server. The NFS server can be restarted without affecting the clients and the cookie remains intact.

Using NFS, authentication only occurs when the client is attempting to mount to a remote filesystem. The NFS server uses the /etc/hosts.allow and /etc/hosts.deny files to determine if a particular host should be specifically permitted or prevented access via NFS. Then, the NFS server refers to the /etc/exports file to uncover that host's privileges for the various mounts available. After granting access, any file and directory operations are sent to the server using remote procedure calls.

WarningWarning
 

NFS mount privileges are granted specifically to a host, not a user. If you grant a host access to a particular part of your hard drive with NFS, users of that machine will have access to your shared data.

When configuring the /etc/exports file, be extremely careful when sharing directories with read-write permissions (rw) to a remote host. Users of remote systems mounting your export will be able to modify data in the exported filesystem.

NFS and portmap

NFS relies upon remote procedure calls (RPC) to function. portmap is required to map 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. portmap then redirects the client to the proper port number to communicate with its intended 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. If, for some reason, the portmap service unexpectedly quits, restart portmap and any services running when it was started.

The portmap service can be used with the host access files (/etc/hosts.allow and /etc/hosts.deny) to control which remote systems are permitted to use RPC-based services on your machine. See Chapter 9 for more information. Access control rules for portmap will affect all RPC-based services. Alternatively, you can specify each of the NFS RPC daemons to be affected by a particular access control rule. The man pages for rpc.mountd and rpc.statd contain information regarding the precise syntax of these rules.

portmap Status

As portmap provides the coordination between RPC services and the port numbers utilized to communicate with them, it is useful to be able to get a picture of the current RPC services using portmap when troubleshooting. The rpcinfo command shows each RPC-based service with its port number, RPC program number, version, and IP protocol type (TCP or UDP).

To make sure the proper NFS RPC-based services are enabled for portmap, rpcinfo can be useful:

[root@bleach /]# rpcinfo -p some.machine.com
   program vers proto   port
    100000    2   tcp    111  portmapper
    100000    2   udp    111  portmapper
    100024    1   udp   1024  status
    100024    1   tcp   1024  status
    100011    1   udp    819  rquotad
    100011    2   udp    819  rquotad
    100005    1   udp   1027  mountd
    100005    1   tcp   1106  mountd
    100005    2   udp   1027  mountd
    100005    2   tcp   1106  mountd
    100005    3   udp   1027  mountd
    100005    3   tcp   1106  mountd
    100003    2   udp   2049  nfs
    100003    3   udp   2049  nfs
    100021    1   udp   1028  nlockmgr
    100021    3   udp   1028  nlockmgr
    100021    4   udp   1028  nlockmgr
[root@bleach /]#

The -p option probes the portmapper on the specified host, or defaults to localhost if no specific host is listed. Other options are available from the rpcinfo man page.

From the output above, various NFS services can be seen running. If one of the NFS services does not start up correctly, portmap will be unable to map RPC requests from clients for that service to the correct port. In many cases, restarting NFS as root (service nfs restart) will cause those service to correctly register with portmap and begin working.