Setting Up an NFS Server

Prerequisites

Install the following package:

• nfs-utils

Run chkconfig to cause nfs to start when the system enters multiuser mode:

# /sbin/chkconfig nfs on

Start nfs:

# /etc/rc.d/init.d/nfs start

The nfs init script starts mountd, nfsd, and rquotad.

The portmap utility (part of the portmap package; refer to "RPC Network Services" on page 377) must be running to enable reliable file locking.

Notes

SELinux

When SELinux is set to use a targeted policy, NFS is protected by SELinux. You can disable this protection if necessary. For more information refer to "Setting the Targeted Policy with system-config-securitylevel" on page 402.

Firewall

If the system is running a firewall, you generally need to open TCP port 111 for portmap, TCP ports 1013 and 1016 for mountd, and TCP port 2049 for nfs. If these ports do not allow NFS access, use rpcinfo p (page 423) to determine the TCP ports that the local server uses for these services and then open those ports. For information on using the Red Hat Linux graphical firewall tool, see "Opening other ports" on page 768. For more general information, see Chapter 25, which details iptables.

JumpStart: Configuring an NFS Server Using system-config-nfs

To display the NFS Server Configuration window (Figure 22-2), enter the command system-config-nfs. From KDE select Main menu: Administration Server Settings NFS or from GNOME select System: Administration Server Settings NFS. From this window you can generate an /etc/exports file, which is almost all there is to setting up an NFS server. If the system is running a firewall, see "Notes" in the preceding section. The system-config-nfs utility allows you to specify which directory hierarchies are shared and how they are shared using NFS. Each exported hierarchy is called a share.

Figure 22-2. NFS Server Configuration window

To add a share, click Add on the toolbar. To modify a share, highlight the share and click Properties on the toolbar. Clicking Add displays the Add NFS Share window, while clicking Properties displays the Edit NFS Share window. These windows are identical except for their titles.

The Add/Edit NFS Share window has three tabs: Basic, General Options, and User Access. On the Basic tab (Figure 22-3) you can specify the pathname of the root of the shared directory hierarchy, the names or IP addresses of the systems (hosts) that the hierarchy will be shared with, and whether users from the specified systems will be able to write to the shared files.

Figure 22-3. Edit NFS Share window

The selections in the other two tabs correspond to options that you can specify in the /etc/exports file. Following is a list of the check box descriptions in these tabs and the option each corresponds to:

General Options tab

Allow connections from ports 1023 and higher: insecure (page 686)

Allow insecure file locking: no_auth_nlm or insecure_locks (page 686)

Disable subtree checking: no_subtree_check (page 686)

Sync write operations on request: sync (page 686)

Force sync of write operations immediately: no_wdelay (page 686)

Hide filesystems beneath: nohide (page 686)

Export only if mounted: mountpoint (page 686)

User Access tab

Treat remote root user as local root: no_root_squash (page 687)

Treat all client users as anonymous users: all_squash (page 688)

Local user ID for anonymous users: anonuid (page 688)

Local group ID for anonymous users: anongid (page 688)

After making the changes you want, click OK to close the Add/Edit NFS Share window and click OK again to close the NFS Server Configuration window. There is no need to restart any daemons.

Exporting a Directory Hierarchy

Exporting a directory hierarchy makes the directory hierarchy available for mounting by designated systems via a network. "Exported" does not mean "mounted": When a directory hierarchy is exported, it is placed in the list of directory hierarchies that can be mounted by other systems. An exported directory hierarchy may be mounted (or not) at any given time. A server holds three lists of exported directory hierarchies:

• /etc/exports Access control list for exported directory hierarchies (discussed in the next section). The system administrator can modify this file by editing it or by running system-config-nfs.

• /var/lib/nfs/xtab Access control list for exported directory hierarchies. Initialized from /etc/exports when the system is brought up. Read by mountd when a client asks to mount a directory hierarchy. Modified by exportfs (page 688) as directory hierarchies are mounted and unmounted by NFS.

• Kernel's export table List of active exported directory hierarchies. The kernel obtains this information from /var/lib/nfs/xtab. You can display this table by giving the command cat /proc/fs/nfs/exports.

Tip: Exporting symbolic links and device files

When you export a directory hierarchy that contains a symbolic link, make sure the object of the link is available on the client (remote) system. If the object of the link does not exist on a client system, you must export and mount it along with the exported link. Otherwise, the link will not point to the file it points to on the server.

A device file refers to a Linux kernel interface. When you export a device file, you export that interface. If the client system does not have the same type of device, the exported device will not work. From a client, you can use mount's nodev option (page 677) to prevent device files on mounted directory hierarchies from being used as devices.

A mounted filesystem with a mount point within an exported filesystem will not be exported with the exported filesystem. You need to explicitly export each filesystem that you want exported, even if it resides within an already exported filesystem. For example, when you have two filesystems, /opt/apps and /opt/apps/oracle, residing on two partitions to export, you must export each explicitly, even though oracle is a subdirectory of apps. Most other subdirectories and files are exported automatically.

/etc/exports: Holds a List of Exported Directory Hierarchies

The /etc/exports file is the access control list for exported directory hierarchies that NFS clients can mount; it is the only file you need to edit to set up an NFS server. The exports file controls the following aspects:

• Which clients can access files on the server

• Which directory hierarchies on the server each client can access

• How each client can access each directory hierarchy

• How client usernames are mapped to server usernames

• Various NFS parameters

Each line in the exports file has the following format:

export-point client1(options) [client2(options) ... ]

where export-point is the absolute pathname of the root directory of the directory hierarchy to be exported, client1-n is the name of one or more clients or is one or more IP addresses, separated by SPACEs, that are allowed to mount the export-point. The options, which are described in the next section, apply to the preceding client.

Either you can use system-config-nfs (page 683) to make changes to exports or you can edit this file directly. The following simple exports file gives grape read and write access and gives speedy readonly access to the files in /home:

# cat /etc/exports /home grape(rw,sync) /home speedy(ro,sync)

In each case, access is implicitly granted for all subdirectories. For historical reasons, exportfs complains when you do not specify either sync or async. You can use IP addresses and include more than one system on a line:

# cat /etc/exports /home grape(rw,sync) speedy(ro,sync) 192.168.0.22(rw,sync)

General Options

This section lists default options first, followed by non-default options (enclosed in parentheses). Refer to the exports man page for more information.

auth_nlm (no_auth_nlm) or secure_locks (insecure_locks)

Causes the server to require authentication of lock requests (using the NLM [NFS Lock Manager] protocol). Use no_auth_nlm for older clients when you find that only files that anyone can read can be locked.

mountpoint[=path]

Allows a directory to be exported only if it has been mounted. This option prevents a mount point that does not have a directory hierarchy mounted on it from being exported and prevents the underlying mount point from being exported. Also mp.

nohide (hide)

When a server exports two directory hierarchies, one of which is mounted on the other, a client has to mount both directory hierarchies explicitly to access both. When the second (child) directory hierarchy is not explicitly mounted, its mount point appears as an empty directory and the directory hierarchy is hidden. The nohide option causes the underlying second directory hierarchy to appear when it is not explicitly mounted, but this option does not work in all cases.

ro (rw)

(readonly) Permits only read requests on an NFS directory hierarchy. Use rw to permit read and write requests.

secure (insecure)

Requires that NFS requests originate on a privileged port (page 1049) so that a program without root permissions cannot mount a directory hierarchy. This option does not guarantee a secure connection.

subtree_check (no_subtree_check)

Checks subtrees for valid files. Assume that you have an exported directory hierarchy that has its root below the root of the filesystem that holds it (that is, an exported subdirectory of a filesystem). When the NFS server receives a request for a file in that directory hierarchy, it performs a subtree check to confirm the file is in the exported directory hierarchy.

Subtree checking can cause problems with files that are renamed while opened and, when no_root_squash is used, files that only root can access. The no_subtree_check option disables subtree checking and can improve reliability in some cases.

For example, you may need to disable subtree checking for home directories. Home directories are frequently subtrees (of /home), are written to often, and can have files within them frequently renamed. You would probably not need to disable subtree checking for directory hierarchies that contain files that are mostly read, such as /usr.

sync (async)

(synchronize) Specifies that the server is to reply to requests only after disk changes made by the request are written to disk. The async option specifies that the server does not have to wait for information to be written to disk and can improve performance, albeit at the cost of possible data corruption if the server crashes or the connection is interrupted.

Because the default changed with release 1.0.0 of nfs-utils, exportfs displays a warning when you do not specify either sync or async.

wdelay (no_wdelay)

(write delay) Causes the server to delay committing write requests when it anticipates that another, related request follows, thereby improving performance by committing multiple write requests within a single operation. The no_wdelay option does not delay committing write requests and can improve performance when the server receives multiple, small, unrelated requests.

User ID Mapping Options

Each user has a UID number and a primary GID number on the local system. The local /etc/passwd and /etc/group files map these numbers to names. When a user makes a request of an NFS server, the server uses these numbers to identify the user on the remote system, raising several issues:

• The user may not have the same ID numbers on both systems and may therefore have owner access to files of another user (see "NIS and NFS" for a solution).

• You may not want the root user on the client system to have owner access to root-owned files on the server.

• You may not want a remote user to have owner access to some important system files that are not owned by root (such as those owned by bin).

Security: Critical files in NFS-mounted directories should be owned by root

Despite the mapping done by the root-squash option, the root user on a client system can use su to assume the identity of any user on the system and then access that user's files on the server. Thus, without resorting to all-squash, you can protect only files owned by root on an NFS server. Make sure that rootand not bin or another userowns and is the only user who can modify or delete all critical files within any NFS-mounted directory hierarchy.

Taking this precaution does not completely protect against an attacker with root privileges, but it can help protect a system from less experienced malicious users.

Owner access means that the remote user can execute, remove, orworsemodify the file. NFS gives you two ways to deal with these cases:

• You can use the root_squash option to map the ID number of the root user on a client to the nfsnobody user on the server.

• You can use the all-squash option to map all NFS users on the client to nfsnobody on the server.

The /etc/passwd file shows that nfsnobody has a UID and GID of 65534. You can use the anonuid and anongid options to override these values.

NIS and NFS

When you use NIS (page 655) for user authorization, users automatically have the same UIDs on both systems. If you are using NFS on a large network, it is a good idea to use a directory service such as LDAP (page 1040) or NIS for authorization. Without such a service, you must synchronize the passwd files on all the systems manually.

root_squash (no_root_squash)

Maps requests from root on a remote system so that they appear to come from the UID for nfsnobody, an unprivileged user on the local system, or as specified by anonuid. Does not affect other sensitive UIDs such as bin. The no_root_squash option turns off this mapping so that requests from root appear to come from root.

no_all_squash (all_squash)

Does not change the mapping of users making requests of the NFS server. The all_squash option maps requests from all users, not just root, on remote systems to appear to come from the UID for nfsnobody, an unprivileged user on the local system, or as specified by anonuid. This option is useful for controlling access to exported public FTP, news, and other directories.

anonuid=un and anongid=gn

Set the UID or the GID of the anonymous account to un or gn, respectively. NFS uses these accounts when it does not recognize an incoming UID or GID and when instructed to do so by root_squash or all_squash.

showmount: Displays NFS Status Information

Without any options, the showmount utility displays a list of systems that are allowed to mount local directories. To display information for a remote system, give the name of the remote system as an argument. You typically use showmount to display a list of directory hierarchies that a server is exporting. The information that showmount provides may not be complete, however, because it depends on mountd and trusts that remote servers are reporting accurately.

In the following example, bravo and grape can mount local directories, but you do not know which ones:

# /usr/sbin/showmount Hosts on localhost: bravo.tcorp.com grape.tcorp.com

If showmount displays an error such as RPC: Program not registered, NFS is not running on the server. Start NFS on the server with the nfs init script (page 682).

a

(all) Tells which directories are mounted by which remote systems. This information is stored in /etc/exports.

# /usr/sbin/showmount -a All mount points on localhost: bravo.tcorp.com:/home grape.tcorp.com:/home

e

(exports) Displays a list of exported directories.

# /usr/sbin/showmount -e Export list for localhost: /home bravo.tcorp.com,grape.tcorp.com

exportfs: Maintains the List of Exported Directory Hierarchies

The exportfs utility maintains the kernel's list of exported directory hierarchies. Without changing /etc/exports, exportfs can add to or remove from the list of exported directory hierarchies. An exportfs command has the following format:

/usr/sbin/exportfs [options] [client:dir ...]

where options is one or more options (as detailed in the next section), client is the name of the system that dir is exported to, and dir is the absolute pathname of the directory at the root of the directory hierarchy being exported.

The system executes the following command when it comes up (it is in the nfs init script). This command reexports the entries in /etc/exports and removes invalid entries from /var/lib/nfs/xtab (page 684) so that /var/lib/nfs/xtab is synchronized with /etc/exports:

# exportfs -r

Replace the r with a to export only the entries in /etc/exports. Remove an exported directory hierarchy with the u option; remove all exported directory hierarchies with the ua options.

Options

a

(all) Exports directory hierarchies specified in /etc/exports. This option does not unexport entries you have removed from exports (that is, it does not remove invalid entries from /var/lib/nfs/xtab); use r to perform this task.

i

(ignore) Ignores /etc/exports; uses what is specified on the command line only.

o

(options) Specifies options. You can specify options following o the same way you do in the exports file. For example, exportfs i o ro speedy:/home/sam exports /home/sam on the local system to speedy for readonly access.

r

(reexport) Reexports the entries in /etc/exports and removes invalid entries from /var/lib/nfs/xtab so that /var/lib/nfs/xtab is synchronized with /etc/exports.

u

(unexport) Makes an exported directory hierarchy no longer exported. If a directory hierarchy is mounted when you unexport it, you will see the message Stale NFS file handle if you try to access the directory hierarchy from the remote system.

v

(verbose) Provides more information. Displays export options when you use exportfs to display export information.

Testing the Server Setup

From the server, run the nfs init script with an argument of status. If all is well, the system displays something similar to the following:

# /sbin/service nfs status rpc.mountd (pid 15795) is running... nfsd (pid 15813 15812 15811 15810 15809 15808 15807 15806) is running... rpc.rquotad (pid 15784) is running...

Next, from the server, use rpcinfo to make sure NFS is registered with portmap:

$ /usr/sbin/rpcinfo -p localhost | grep nfs   100003  2  udp  2049 nfs   100003  3  udp  2049 nfs

Repeat the preceding command from the client, replacing localhost with the name of the server. The results should be the same.

Finally, try mounting directory hierarchies from remote systems and verify access.