All Red Hat Linux documents are copyrighted to Red Hat Inc.

9.2. NFS Server Configuration Files

Configuring a system to share files and directories using NFS is a simple process. Every file system being exported to remote users via NFS, as well as the access rights relating to those file systems, is located in the /etc/exports file. This file is read by the exportfs command to give rpc.mountd and rpc.nfsd the information necessary to allow the remote mounting of a file system by an authorized host.

The exportfs command allows the root user to selectively export or unexport directories without restarting the NFS service. When exportfs is passed the proper options, the file systems to be exported are written to /var/lib/nfs/xtab. Since rpc.mountd refers to the xtab file when deciding access privileges to a file system, changes to the list of exported file systems take effect immediately.

Various options are available when using exportfs:

  • -r — Causes all directories listed in /etc/exports to be exported by constructing a new export list in /etc/lib/nfs/xtab. This option effectively refreshes the export list with any changes that have been made to /etc/exports.

  • -a — Causes all directories to be exported or unexported, depending on the other options passed to exportfs.

  • -o options — Allows the user to specify directories to be exported that are not listed in /etc/exports. These additional file system shares must be written in the same way they are specified in /etc/exports. This option is used to test an exported file system before adding it permanently to the list of file systems to be exported.

  • -i — Ignore /etc/exports; only options given from the command line are used to define exported file systems.

  • -u — Unexports directories from being mounted by remote users. The command exportfs -ua effectively suspends NFS file sharing while keeping the various NFS daemons up. To allow NFS sharing to continue, type exportfs -r.

  • -v — Verbose operation, where the file systems being exported or unexported are displayed in greater detail when the exportfs command is executed.

If no options are passed to the exportfs command, it displays a list of currently exported file systems.

Changes to /etc/exports can also be read by reloading the NFS service with the service nfs reload command. This keeps the NFS daemons running while re-exporting the /etc/exports file.

9.2.1. /etc/exports

The /etc/exports file controls which file systems are exported to remote hosts and specifies options. Blank lines are ignored, comments can be made by starting a line with the hash mark (#), and long lines can be wrapped with a backslash (\). Each exported file system should be on its own individual line. Lists of authorized hosts placed after an exported file system must be separated by space characters. Options for each of the hosts must be placed in parentheses directly after the host identifier, without any spaces separating the host and the first parenthesis.

In its simplest form, /etc/exports only needs to know the directory to be exported and the hosts permitted to use it:

/some/directory bob.example.com
/another/exported/directory 192.168.0.3

After re-exporting /etc/exports with the /sbin/service nfs reload command, the bob.example.com host will be able to mount /some/directory and 192.168.0.3 can mount /another/exported/directory. Because no options are specified in this example, several default NFS preferences take effect:

  • ro — Read-only. Hosts mounting this file system will not be able to change it. To allow hosts to make changes to the file system, the rw (read-write) option must be specified.

  • async — Allows the server to write data to the disk when it sees fit. While this is not important if the host is accessing data as read-only, if a host is making changes to a read-write file system and the server crashes, data could be lost. By specifying the sync option, all file writes must be committed to the disk before the write request by the client is actually completed. This may lower performance.

  • wdelay — Causes the NFS server to delay writing to the disk if it suspects another write request is imminent. This can improve performance by reducing the number of times the disk must be accessed by separate write commands, reducing write overhead. The no_wdelay option turns off this feature, but is only available when using the sync option.

  • root_squash — Strips root users connected remotely from having root privileges by assigning them the nobody userid. This effectively "squashes" the power of the remote root user to the lowest local user, preventing remote root users from acting as though they were the root user on the local system. Alternatively, the no_root_squash option turns off root squashing. To squash every remote user, including root, use the all_squash option. To specify the user and group IDs to use with remote users from a particular host, use the anonuid and anongid options, respectively. In this case, a special user account can be created for remote NFS users to share and specify (anonuid=<uid-value>,anongid=<gid-value>), where <uid-value> is the userid number and <gid-value> is the group ID number.

In order to override these defaults, you must specify an option that takes its place. For example, if you do not specify rw, then that export will only be shared read-only. Each default for every exported file system must be explicitly overridden. Additionally, other options are available where no default value is in place. These include the ability to disable sub-tree checking, allow access from insecure ports, and allow insecure file locks (necessary for certain early NFS client implementations). See the exports man page for details on these lesser used options.

When specifying hostnames, use the following methods:

  • single host — Where one particular host is specified with a fully qualified domain name, hostname, or IP address.

  • wildcards — Where a * or ? character is used to take into account a grouping of fully qualified domain names that match a particular string of letters. Wildcards are not to be used with IP addresses; however, they may accidently work if reverse DNS lookups fail.

    However, be careful when using wildcards with fully qualified domain names, as they tend to be more exact than you would expect. For example, the use of *.example.com as wildcard will allow sales.example.com to access an exported file system, but not bob.sales.example.com. To match both possibilities, as well as sam.corp.example.com, you would have to provide *.example.com *.*.example.com.

  • IP networks — Allows the matching of hosts based on their IP addresses within a larger network. For example, 192.168.0.0/28 will allow the first 16 IP addresses, from 192.168.0.0 to 192.168.0.15, to access the exported file system but not 192.168.0.16 and higher.

  • netgroups — Permits an NIS netgroup name, written as @<group-name>, to be used. This effectively puts the NIS server in charge of access control for this exported file system, where users can be added and removed from an NIS group without affecting /etc/exports.

WarningWarning
 

The format of the /etc/exports file is very precise, particularly in regards to use of the space character. Remember to always separate exported file systems from hosts and hosts from one another with a space character. However, there should be no other space characters in the file except on comment lines.

For example, the following two lines do not mean the same thing:

/home bob.example.com(rw)
/home bob.example.com (rw)

The first line allows only users from bob.example.com read-write access to the /home directory. The second line allows users from bob.example.com to mount the directory read-only (the default), but the rest of the world can mount it read-write.

© Copyright 2003-2014 www.php-editors.com. The ultimate PHP Editor and PHP IDE site.