Configuring an NFS Server

Setting up your FreeBSD machine to be an NFS server involves a one-line addition to /etc/rc.conf:

nfs_server_enable="YES"

Also, make sure that rpcbind_enable (portmap_enable prior to FreeBSD 5.0) is set to "YES" because it is disabled by default unless you override it. The rpcbind (or portmap) daemon needs to be running in order for NFS to work because the NFS server needs a mechanism by which to tell its clients which port to connect to. UDP services operate with only one "connection" per port, so while initial connections to the NFS server take place on the server port 2049, these connections are mapped by remote procedure call (RPC) services, provided by rpcbind, to a new and unused server port. Note that rpcbind services are fairly insecure and subject to a number of recurring security issues; for this reason, it's not a good idea to have an NFS server exposed to the Internet without a firewall protecting it. See Chapter 30, "Network Security," for more on firewalls.

When you set the nfs_server_enable option and reboot (or run /etc/rc.d/nfsserver start), FreeBSD starts two kinds of daemon processesthree if you count rpcbindafter reading the contents of the /etc/exports file to determine what parts of the filesystem to share over NFS. The following sections look at each of these components to explain what they do and how to control them.

NFS Daemon (nfsd)

The NFS server daemon, the equivalent of sshd or httpd, is nfsd. A certain number of nfsd processes are started when the network is initialized (the default is four); these processes are assigned to service NFS clients when they connect, one process per client. In the default configuration, a maximum of four clients can connect to your NFS server at the same time. You can tune this with the nfs_server_flags setting in /etc/rc.conf, of which the following is the default:

nfs_server_flags="-u -t -n 4"

The -n flag can be set to any number you like; set it to the highest number of concurrent NFS clients you expect to be connected to your server at any one time. The -t and -u flags tell the nfsd processes to serve both TCP and UDP clients. Other flags are available for you to tweak, if you like. For instance, if your machine has multiple network interfaces, you can specify -h 64.41.131.102 among the other flags to bind the NFS servers to the interface with the address 64.41.131.102. (You can also use a hostname instead of an IP address.) This can be necessary because the UDP mechanism is such that if you don't tell nfsd for which specific IP addresses it should serve requests, its responses are not guaranteed to emanate from the address that the client contacted. You can list as many addresses as you need with multiple -h flags. For example, let's say you have a server acting as a gateway with two network cardsone on the "inside" and one on the "outside" of the network. Your "inside" card has two IP addresses bound to it, and you want to serve NFS shares only to clients on the inside. You can set up NFS like this:

nfs_server_flags="-u -t -n 4 -h 64.41.131.102 -h 64.41.131.116"

Then, you can block access to the NFS service on the outside interface with an IPFW rule, like so:

ipfw add deny udp from any to 64.41.131.10 nfsd

Refer to "Using a Firewall," in Chapter 30, for more information on how to configure firewall rules using IPFW.

NFS Mount Daemon (mountd)

Whereas nfsd is the program that provides the connection end of each individual NFS mount, a second program is in charge of listening for new NFS client requests (on TCP port 2049). This program is mountd, the mount daemon. It is executed automatically along with the nfsd processes during the network setup procedure at boot time if nfs_server_enable is set to "YES".

mountd takes incoming NFS connections and passes them to nfsd processes. It's also in charge of keeping track of the NFS shares you have specified in /etc/exports. To restart NFS services after making changes to /etc/exports, you need to send an HUP signal to mountd, as you will see shortly.

There aren't too many useful options for mountd. The default settings in /etc/defaults/rc.conf, which you can override in /etc/rc.conf, are as follows:

mountd_flags="-r"

The -r flag allows mountd to serve regular files rather than only directories, to maintain compatibility with certain diskless workstations that boot via NFS. The -l flag allows you to log all NFS mount requests, and the -n flag allows NFS shares to be mounted to remote systems such as Windows PCs that don't share the same ownership and permissions model as UNIX.

Determining What to Share with the /etc/exports File

The /etc/exports file lists what directory trees should be shared via NFS as well as who should be allowed to share them. If /etc/exports does not exist or is not readable at the time the network interfaces are brought up at boot time, the nfsd and mountd processes are not started.

The full format of /etc/exports is defined in man exports. A basic export line specifies one or more directories that should be exported (shared), any of several options, and then an optional list of hosts (by IP address, network, netgroup, or hostname) allowed to share the specified directories. For example, the following line shares the /home directory and all its subdirectories to anybody who connects:

/home -alldirs

Note that the -alldirs option can only be specified if the share is the mount point of a filesystem (for example, /usr or /var). If it isn'tfor example, if /home is not a separate filesystem but a directory within anotherthe share will not be made available.

A share that can be accessed only by three specified hosts and is read-only would look like this:

/usr2 -ro -alldirs stripes.example.com spots.example.com 64.41.131.165

Tip

You can create groups of hosts by specifying them in the file /etc/netgroup, which does not exist in the default installation. A group can be specified in the following form:

groupname (host, user, domain) (host, user, domain) ...

For instance, to create a group called desktops that contains three particular hosts (named sol, luna, and terra), the line would look like this:

desktops (sol,,) (luna,,) (terra,,)

A netgroup defined on usernames would look like this:

developers (,frank,) (,bob,) (,alice,)

You can then use any of these netgroup names instead of hostnames in /etc/exports to confine an NFS share to members of that group.

File ownership in an NFS share is mapped based on the UIDs of each file and directory. If the usernames and UIDs on the server and client machines are the same (for instance, if the machines' logins are synchronized via NIS or Kerberos), the permissions will match. However, if UID 1045 maps on the server to the username bill, but UID 1045 on the client is john, John will own the files in the share that the server thinks Bill owns. When exporting a share containing files owned by many different users, make sure the infrastructure is in place to provide consistent mappings between UIDs and usernames on all the machines on your network.

You can use the -maproot=username or -maproot=UID option to map ownership so that the username matching username or the user ID matching UID on the client machine will have full root permissions in the share. For example, here's how to share the entire filesystem of the NFS server with anybody in the 64.41.131 network, with the client user frank having full read/write access to all the files:

/ -maproot=frank -network 64.41.131 -mask 255.255.255.0

After making any changes to /etc/exports, you need to restart the mountd process (assuming it's already running). Do this by running /etc/rc.d/mountd restart, or by accessing the runtime PID file directly:

# kill -HUP `cat /var/run/mountd.pid`

Note

You can't have multiple export lines for mount points within the same partition or filesystem. This is to prevent problems in cases where the export permissions for different shares in the same filesystem would conflict. An NFS client cannot access one filesystem from within another that it has mounted, and the same access permissions must apply for all shares within a filesystem. The following setup is illegal:

/home/frank 64.41.131.102 /home/joe 64.41.131.102

However, this one is correct:

/home/frank /home/joe 64.41.131.102

You can use the showmount program (with the e, or "show exports list" option) to display the valid shares and their permissions. This is how you can tell whether your /etc/exports setup is valid:

# showmount -e Exports list on localhost: /usr                             Everyone /home/frank                      64.41.131.102 /home/joe                        64.41.131.102 /                                64.41.131.0