Network File System (NFS) is the native local area networking protocol not only for Linux, but for all UNIX-like operating systems. As you may have already discovered, the Linux implementations of NFS can be a bear to configure. If NFS has been giving you fits, you’ve come to the right place. In this Daily Drill Down, I’ll reveal the tricks, secrets, and magical incantations needed to get NFS working on your system.

You’ll begin by surveying precisely what you’ll need to install—on the client as well as the server—to work with NFS. You’ll then learn how to export directories from the NFS server so that they’re available to other computers on your network. Next, you’ll learn how to mount remote directories on the client machines, just as if they were part of the client machine’s file system. You’ll also learn how to deal with the various error messages you’re likely to encounter. By the time you’ve finished reading this Daily Drill Down, you’ll have mastered all the essentials of NFS, and you’ll be well on your way to taking full advantage of this powerful, transparent technology.

Part of the problem with Linux implementations of NFS lies in the fact that Linux users are going through a transition. Since Linux version 2.2, NFS has been directly supported in the kernel. That’s good for performance. But it also means that all those NFS utilities need to be updated to deal with the kernel changes—and so does the documentation. The result, predictably, is buggy software and out-of-date documentation. Perhaps you’ve been lucky and gotten NFS working without too much trouble, but many Linux users complain that they can’t get past the error messages.

What about Samba?
Before you get started with squashed roots and other NFS mysteries, take a moment to consider whether NFS is right for your network. For one thing, NFS works only with Linux (and other UNIX-like operating systems). If your network includes Windows 95/98/NT boxes, you may wish to consider using Samba instead (for more information on basic Samba configuration, see ”Configuring basic Samba”).

In brief, Samba is a cross-platform networking protocol that implements the messaging system native to Microsoft Windows. The Linux implementation of this messaging technology is very neat—so neat, in fact, that more than a few Linux-only networks are running Samba, even though there aren’t any Windows boxes on these networks! Still, Samba isn’t as tightly integrated with Linux as NFS is. For example, it’s easy to configure NFS so that all the needed software runs automatically on startup and all the remote directories are mounted without user intervention. (You can do this with Samba, too, of course, but it requires more work.)

Squash that root
Before you get started with NFS, understand that NFS isn’t the most secure networking technology. (One colleague says that NFS actually stands for “no flippin’ security.”) Like the Internet protocols, it dates from those wondrous days when networks were small, you knew everyone who used it, and everyone behaved nicely. Created in the organizational equivalent of Mr. Roger’s Neighborhood, NFS assumes that security is no big deal; if a user has logged on to one of the networked systems and supplied the correct username and password, this system becomes a trusted client. If you logged on to a client system as root, you could log on to the server as root—and of course, you wouldn’t do anything malicious, would you?

Those days are gone, unless you’re setting up a small network at home that’s not connected to the Internet. Once you connect your network to the Internet, though, there’s a chance unauthorized intruders could gain root user status—and with the NFS of yore, they’d quite quickly gain root user status on any of the systems on the network. The same goes for internal intruders, such as an employee hunting for valuable information that could be provided to a competitor in exchange for a job offer. (Yes, it happens.)

For this reason, today’s NFS implementations, including those found on Linux, implement a feature called root squashing (it’s enabled by default). In brief, root squashing comes into play when you establish a root user session on a client and try to access server directories that are owned by the root user. NFS steps in and changes the client root user’s ID to an anonymous ID, nobody, which is specifically designed to make it very difficult to do any damage. The nobody user might well be named Nowhere Man after The Beatles’ song; this user doesn’t know what he or she is missing, because most of the server’s file system is quite deliberately protected from view.

Root squashing helps to solve the underlying security deficiencies of NFS, at least at the level of leaving servers vulnerable to root user attacks. But this leads us to NFS Gotcha #1. On most Linux distributions, the NFS mount utility is configured so that you can’t run it from your ordinary user account; you see the message Only root can do that. So you switch to root and try to mount the remote directory. But you’re refused permission! Why? As far as the server is concerned, you’re trying to log on as nobody, and this user has very few privileges. So what should you do? Disable root squashing? That’s not a very good idea, since it leaves the non-squashed system open to any intruder who gains root user status somewhere on the network. For this reason, you’ll want to set up NFS so that ordinary users can access their own directories, or publicly accessible directories, on remote servers. You’ll learn how later in this Daily Drill Down. (In brief, what’s involved is defining the remote directory in /etc/fstab as if it were a user-mountable device, such as a CD-ROM or floppy disk drive.)

You can set up NFS so that ordinary users can mount the directories that they own on remote servers. But this leads us to NFS Gotcha #2. For ordinary user accounts, NFS requires that users have exactly the same username—and numerical user IDs—on both systems (the server and the client). On lothlorien, I’m set up as the user named bryan (ID 501), and I belong to the group named strider (ID 101). Unless rivendell knows me as the bryan (ID 501) who belongs to the strider group (ID 101), NFS isn’t happy. In short, in order to set up NFS so that users can mount directories on a remote NFS server, you need to make sure that their accounts are defined exactly the same way on both the client and the server.

“So that’s why it didn’t work,” you’re probably thinking. “Why isn’t this explained more clearly?” It is, actually—it’s in the man (manual) pages. All too often, how-to authors assume you’ve read the man pages and memorized everything that’s in them. That’s understandable, but it would be nice if they would at least mention that they’re assuming some knowledge—and in this case, a considerable amount of knowledge.

Getting NFS to work: an overview
To get NFS working successfully, you’ll tackle the following tasks:

  • Make sure your user and group IDs match on the client and server systems.
  • On the server, modify /etc/hosts.allow and /etc/hosts.deny so that the server will accept portmap requests from clients on your network.
  • Make sure all the needed daemons and utilities are running happily.
  • On the server, create or modify the /etc/exports file so that the server will make specified directories available to other machines on the network.
  • On the client, modify /etc/fstab so that the client will automatically load the exported directories when you start the client system.

Making sure user and group IDs are the same
NFS comes into its own when ordinary users are able to access their remote directories smoothly, as if these directories were part of the user’s file system. However, as I explained earlier, NFS won’t work smoothly (or at all) if the user and group names and numerical IDs aren’t the same on both systems. If there are discrepancies, you must fix them before proceeding.

This isn’t the place to go into all the details of modifying user and group names. Chances are you can use a user-friendly utility for this purpose, such as the KDE user manager or, on Red Hat systems, linuxconf. If you prefer the command line, you can use usermod to make the necessary changes—but don’t forget to use chown -R (in recursive mode) to change the ownership of all the files in the user’s home directories.

Modifying /etc/hosts.allow and /etc/hosts.deny
Get started by securing your system. You’ll modify the /etc/hosts.allow and /etc/hosts.deny files so that you’re protected against a whole series of possible attacks. This protection isn’t bulletproof, to be sure, but it will eliminate a number of tricks that the script kiddies have been pulling for years.

  1. Open a terminal window and switch to superuser (type su followed by your password).
  2. Use your favorite text editor to open /etc/hosts.deny.
  3. On a blank line, type portmap: ALL.
  4. Save the file.
  5. Open /etc/hosts.allow.
  6. On a blank line, type portmap: followed by a space, the IP address of the client machine, a forward slash mark, and the netmask of the client machine. For a Class C network, which is what you’re probably using, the default netmask is If you’re not sure what the client’s netmask is, go to the client, open a terminal window, type ifconfig, and press [Enter]. Look for the IP address and netmask under the Ethernet network interface (eth0, unless the machine has more than one Ethernet card). In /etc/hosts.allow, an example of a valid entry is portmap: If you would like to make the exported directories available to all the machines on your network, you can use a wildcard, as in this example: portmap: 192.168.100.*/
  7. Save the file.

Getting all your daemons in a row
To work with NFS, you will need the following daemons (memory-resident programs) running on both servers and clients:

  • portmap—Accepts remote requests for information and guides these requests to the appropriate port.
  • rpc.mountd—Enables the system to mount and unmount remote NFS directories.
  • nfsd—Serves as the NFS daemon proper.

You should configure all the machines on your network so that they start these daemons at the beginning of each session. On Red Hat systems, you do this with the /usr/sbin/setup utility, a text-mode utility that enables you to specify which system services you want to run. Make sure that your system is running the following services: netfs, nfs, nfslock, portmap, rstatd, and ruserd. (Note: If any of these options aren’t available on the Setup program menu, you need to install the RPM packages for these services.) Other distributions let you specify which services run automatically on startup; check your distribution’s documentation to find out which utility to run.

To make sure you’re running the needed utilities, you can run the startup scripts with the status option. First, switch to the directory where network scripts are stored. On Red Hat and kindred systems, this directory is /etc/rc.d/init.d. Next, type ./portmap status and press [Enter]. You should see a message stating that portmap is running. If not, type ./portmap startup and press [Enter].

Now, type ./nfs status and press [Enter]. You should see a message informing you that rpc.mountd and nfsd are running. If not, type ./nfs start and press [Enter].

At this point, you should have everything running. Just to be sure, type /usr/sbin/rpcinfo -p and press [Enter]. You should see a list of all the running daemons, including their version numbers and the protocol they’re using. If you see an error message such as can’t contact portmapper, Connection refused, or PROG NOT REGISTERED, it means portmap isn’t running or your /etc/hosts.deny and /etc/hosts.allow files aren’t properly configured. Check your configuration, and then restart your system and try the above steps again.

Configuring /etc/exports
Now that you’re sure you have all the daemons working, it’s time to specify which directories you want to make available. When you do, you can also specify which clients will be able to access these directories.

To configure /etc/exports, begin by opening a terminal window and switching to superuser (type su followed by your password). Next, use your favorite text editor to open /etc/exports. On a blank line, type the name of the directory you want to export, followed by a space, and the IP address of the client or clients to which you want to make the directory available. After the IP address, place the export options you want within parentheses. Here’s an example:
/mnt/cdrom 192.168.100.*(ro)

In this example, I’m exporting /home/suzanne to Suzanne’s computer (, and I’m specifying that this directory should be exported with read-write permissions (rw). I’m also exporting the server’s CD-ROM drive (/mnt/cdrom) to all the clients on my network, with read-only permission. With this configuration, I can keep the Linux distribution disc in my CD-ROM drive so that it’s always available, in case anyone needs to grab additional files.

Using exportfs

Before NFS can make use of the modifications you’ve made, you must use the exportfs utility to update the exported directory database, /var/lib/nfs/xtab. This database is needed by the remote mounting daemons. If it isn’t accurate, clients won’t be able to mount the exported directories. To synchronize /etc/exports with the database, type exportfs -rv and press [Enter].

Configuring /etc/fstab on the client
Now you need to configure the clients so that they can access the exported directories automatically. On the client system, create the directories where you want to mount the remote directories. If you’re creating mount points for a user’s directories, be sure to do this from the user’s account so that it will have the correct permissions.

Next, add mount information to /etc/fstab on the client system. The following examples load the directories /home/public and /home/suzanne, which are physically present on the server named rivendell:
rivendell:/home/public /home/suzanne/public nfs
rivendell:/home/suzanne /home/suzanne/rivendell nfs

These lines mount the specified directories to local directories named, respectively, /home/suzanne/public and /home/suzanne/rivendell. The additional options specify the file system type (nfs), read and write block sizes that are larger (and faster) than the default, and the all-important user option, which enables ordinary users to mount and unmount the remote directories without switching to superuser (which, as you’ve already learned, would transform them into nobodies).

Make sure that the server is running, and then restart the client. If you see an error message such as Program not registered, the needed NFS daemons aren’t running on the client system. See the section “Getting all your daemons in a row,” earlier in this Daily Drill Down, to make sure they’re running, and configure the client system so that they run on startup. If you see a message such as Permission denied, there’s a problem on the server side; you may have forgotten to run exportfs.

NFS horizons
Chances are good that you’ve got NFS working successfully—but please keep in mind that some of the earlier versions of the 2.2 kernel don’t work with NFS as smoothly as they should. If you’re still experiencing problems getting NFS running, I suggest that you upgrade to a more recent version of the Linux distribution you’re running, which means you’ll automatically get a more up-to-date version of the kernel.

Happy networking!