Configuring NFS under Linux

In the first installment of IT Corner we looked at how DNS (Domain Name Service) is used to handle name resolution. Continuing our look at TCP/IP services that you may want to maintain on your networks, we look at Network File System (NFS). NFS has a undeserved reputation for being difficult to install, configure, and maintain. In actuality, NFS is quite easy to implement on Linux systems. Further, if you have a Linux machine on a local area network, NFS can give both the Linux and other platform machines greater flexibility for sharing resources.

NFS was developed by Sun Microsystems to prevent the need for users to log in and out of networked machines that had resources the user needed. Sun designed NFS to enable machines of any operating system to work together, sharing files and resources. Sun publishing the NFS specifications, allowing other vendors to modify their systems to work with NFS. This resulted in a completely homogeneous network to the point that NFS is now a de facto standard among UNIX and Linux environments, with strong support in other operating systems. The term NFS refers to both a product and a protocol. The NFS product is a set of protocols for differing tasks. The NFS protocol is the single protocol of the NFS product that handles file access tasks.

NFS allows a client user or application to read and write files that reside on NFS servers. Access to the NFS server is transparent to the application and the user, achieved by logically mounting the NFS resource from the server to the client. The mount of an NFS resource is handled in the same way as any other file system mount using the mount command, although the option “-t nfs” is added to the command to show that NFS is being used. (In practice, most versions of NFS don’t need this option, as it is obvious because of the machine name that this is an NFS request.) For example, to mount the directory /usr/data which is located on the remote machine named maxlinux, mounting to your local directory data, you would issue the following command:

mount -t nfs maxlinux:/usr/data /data

When the mount command is issued, your machine checks with the remote machine (maxlinux in this case) for permission to access the directory. If permission if granted, the remote machine sends a file handle used internally to redirect all requests for that directory on your local machine. Linux (and most UNIX versions) uses the process nfsd to manage NFS access. Whenever you issue a request for anything on the remote maxlinux machine, nfsd handles the transfer.

As with many TCP/IP services, NFS uses the term client to mean any machine that requests resources from another machine, which is the server. Linux can act as both client and server simultaneously, both sharing resources of its own and mounting remote shared resources.

For even a small Linux network such as one at home connecting three or four machines, or in a slightly larger office, NFS offers some benefits. The most important is that NFS allows valuable data and large applications to be kept on a single drive on the network, and all other machines have access to as clients. This prevents you having to keep multiple copies of the data or applications on clients, as well as providing a single location for backups.

NFS implemented under Linux differs slightly from standard UNIX version of NFS in that many of the features needed to support NFS are embedded in the Linux kernel code for the Virtual File System (VFS). Since NFS is UNIX based and goes back many years, the security offered by the basic NFS package is rudimentary. Sun has introduced Secure NFS, implementing an encrypted messaging protocol for added protection against unauthorized access to NFS-mounted file systems, but this version is not available for Linux yet.

Installing NFS

Most Linux kernels have the NFS code linked into the kernel by default. You can confirm NFS support is in the kernel by looking at the /proc/filesystems file. An entry in this file should show a line with the “nfs” service coupled with the command “nodev”, like this:

nodev nfs

If the NFS code is not included, you will have to rebuild the kernel, including the NFS drivers.

As a fast check that NFS is working properly, you can mount a local directory on your own machine (which is perfectly legal with NFS since your machine is simply a client of its own server). To try this create a subdirectory in your filesystem and issue the mount command against an existing directory that is to be mounted. For example, you can mount the directory /usr on the empty directory /nfstest:

mkdir /nfstest

mount localhost:/usr /nfstest

If the mount command is successful you can go into the /tmp/nfstest directory and examine the same file listing as in /usr. If you get an error message like this:

fs type nfs not supported

the NFS code is missing, and you should rebuild the kernel with the NFS drivers linked in.

For your machine to act as an NFS server (allow your directories to be mounted by other clients), you must install both the nfsd and mountd daemons. Both daemons need the program rpc.portmap to function. The startup commands for these two daemons are usually in the /etc/rc.d/rc.inet2 file or /etc/rc.d/rc3.d directory. The section dealing with NFS will look much like this:

	# # Start the various SUN RPC servers.
	if [ -f ${NET}/rpc.portmap ]; then
	# Start the NFS server daemons.
	if [ -f ${NET}/rpc.mountd ]; then
	echo -n " mountd"
	${NET}/rpc.mountd
	fi
	if [ -f ${NET}/rpc.nfsd ]; then
	echo -n " nfsd"
	${NET}/rpc.nfsd
	fi

If your inet2 file doesn't have lines similar to these, add them below the rpc.portmapper startup command. The portmapper startup section will look similar to this:

	# Start the SUN RPC Portmapper.
	if [ -f ${NET}/rpc.portmap ]; then
	echo -n " portmap"
	${NET}/rpc.portmap
	fi

Below these lines, enter the following commands to start the rpcd and mountd daemons:

	if [ -x /usr/sbin/rpc.mountd ]; then
	echo -n " mountd"
	/usr/sbin/rpc.mountd
	fi
	if [ -x /usr/sbin/rpc.nfsd ]; then
	echo -n " nfsd"
	/usr/sbin/rpc.nfsd
	fi

Of course, if the rpc.nfsd and rpc.mountd daemons are not in /usr/sbin, use the proper pathnames.

Server access

The next step in configuring your system as an NFS server is to create a file listing all the clients who can attach to your system and mount directories. This is done with the file /etc/exports. This file contains a list of directories that you allow to be mounted by clients, and the remote systems that can mount them. An example will make the format of this file easier to understand:

	# /etc/exports for merlin
	/usr/database/data chatton(rw) big_roy (rw) wizard (rw)
	/usr/book chatton(rw) wizard (ro)
	/usr/bin/bigapp big_roy(rw) wizard (ro)
	/usr/ftp (ro)

This file shows that the three machines chatton, big_roy, and wizard can mount the local directory /usr/database/data in read-write mode. The directory /usr/book can be mounted read-write by remote machine chatton and read-only by wizard. The /usr/ftp directory can be mounted read-only by any machine that wants to. When no hostname is provided (as with the /usr/ftp directory in the previous example), any machine can mount the directory.

When you are specifying machine names in the /etc/exports file, you can use explicit names or a combination of asterisk and question mark wildcards to match multiple machines. For example, the entry

/usr/tim/book big_*(rw)

allows any machine starting with big_ to mount the directory as read-write.

Mounting NFS Directories

Once NFS is configured, you can use it to mount remote directories on your local machine. The format of the mount command for NFS mounts is

mount -t nfs remote_dir local_dir [-o options]

where remote_dir is the name of the remote machine and directory to be NFS mounted, local_dir is where you want to mount the remote directory, and options are any of the flags used by NFS. Many users leave off the -t nfs component of the mount command, since this format is unique to NFS.

There are many options possible for use with the mount command but only a few are ever used in practice. Valid options are:

	hard This option explicitly tags the directory as hard mounted. This is a default action.
	intr This option allows interrupts to the NFS call.
	rsize This option specifies the datagram size used for read requests (default is 1024 bytes).
	soft This option soft-mounts the directory (instead of hard mounting).
	timeo This option specifies the timeout in tenths of a second for completion of an NFS request (default is 7/10ths).
	wsize This option specifies the datagram size used for write requests (default is 1024 bytes).

The rsize, timeo, and wsize options are followed by an equal sign and the value they are to be assigned. The rsize and wsize options are used primarily to switch the remote machine to another datagram size (in case it uses a larger size than Linux can handle). All NFS options must follow the -o switch on the command line, if the options are set there.

For example, to set the timeout to 2 seconds (20 tenths of a second) on the remote mount of a directory and allow interrupts, you would issue the command:

mount -t nfs wizard:/usr/data /usr/data -o timeo=20,intr

Two of the important NFS mount options deal with hard and soft mounting. The default with NFS is to hard mount a directory. This means is that if NFS is unable to mount a requested volume, it times out, generates an error message, and tries again with double the timeout value. This goes on forever until the remote directory is mounted. Any remote directory that is repeatedly tried until successfully mounted is called a hard mount. A soft mount is one that acts the same way but generates error messages only after a major timeout, which is every 60 seconds. The repetitive NFS error messages are not displayed and you can gain control of the system more easily with a soft mount.

Summary

As you have seen, NFS is easy to implement on a network. Since all current Linux kernels include the NFS code as part of the basic kernel, there’s no real reason not to implement NFS on your network (assuming you have more than one machine).

Configuring the servers with the exports file is simple and easy enough, and a single file can be copied to other machines for generic mounts (such as FTP directories). NFS simplifies the process of sharing directories and files, especially those of applications and large data files, and don’t impose much of a performance hit on the systems. With so little effort required for NFS, go ahead and try it on your systems!