Home / Insights / How to Network Your Files With NFS
Networking 6 min read

We will be implementing an NFS server step by step in this article, exploring methods for simply sharing a directory, and also briefly talking about making users’ home directories live on the server.

Network File System (NFS), is the original file-sharing method among UNIX-based computers. Originally developed by Sun, NFS is still widely used, since it is a (relatively) simple and effective means to provide a centralized file server.

Implementing an NFS Server

We will be implementing an NFS server step by step in this article, exploring methods for simply sharing a directory, and also briefly talking about making users’ home directories live on the server.

The basic premise behind NFS is a simple client/server model. You share directories on the server, the client mounts them, and then it appears to the users on the client machine as just another file system.

Older NFS versions, which most people use for the sake of interoperability, have practically zero security. The server will believe what it’s told about the UID/GID of files, so it should be protected from the Internet. Additionally, it should be limited to only serving files for clients that you designate. The easiest way to limit NFS mounts is with tcpwrappers, configurable via /etc/hosts.allow. Portmap, lockd, rquotad, statd, and mountd should all be limited to networks or specific IP addresses of trusted NFS clients.

The Server

Since Linux’ NFS configuration options are quite similar to other Unix variants, we will be assuming a Linux client and server for this article.

First things first: We should begin by starting the necessary NFS services. On the server side, most distributions have a startup script designed to accomplish this. Running something like /etc/init.d/nfs start will fire up the NFS server properly on most distributions.

Using rpcinfo -p should return a bit of information about which RPC services are running. At a minimum, for NFS to function, you should see: portmap, status, mountd, nfs, and nlockmgr. Any missing items will require that you figure out why they are missing before proceeding. Note that these names are based on the most current nfs-utils package, currently nfs-utils-1.0.6-22. Your specific Linux distribution’s documentation should provide more information about how to make sure everything is started at boot time.

Now on to the fun part: sharing directories. The file /etc/exports is used to specify which file systems should be exported to which clients. This is basically a listing of: “directory machine1(options) machine2(options).”

Examples should make it clear:

  • To share /usr read-only to two IP addresses:
    /usr 192.168.0.1(ro) 192.168.0.2(ro)
  • To share /usr/local read-write to one machine, and read-only to everyone else:
    /usr/local 192.168.0.5(rw) *(ro)

There are many ways to share directories, and many configurable options. Client lists can be netgroups, IP addresses, a single host, wildcards, or IP networks. Refer to “man exports” for more exhaustive details. The server also needs to be told to reread the configuration when it changes. This can be accomplished by sending -HUP to the nfs daemon, or by running exportfs -ra.

If everything was done properly, this server should be ready to serve NFS. The command showmount -e will list the exported file systems. If an RPC error was returned, that generally means a necessary service is not running.

The Clients

Most current Linux distributions will support NFS mounting out of the box. To check for kernel support, run grep nfs /proc/filesystems. If enabled, a few lines mentioning NFS will be present. If not, you’ll need to get a different kernel with built-in NFS support, or compile the module. Running insmod nfs should load the module if it happens to be present already. On the client side, NFS requires a few RPC services before you can successfully mount a remote file system. Portmap, lockd, and statd all need to be running, and should be visible in the output of rpcinfo -p.

You can manually mount an NFS file system as root in the same manner as you would mount a local file system or CDROM. For testing, I created a directory called /mnt/remote. Then ran mount 192.168.0.100:/usr /mnt/remote, where 192.168.0.100 is the NFS server’s IP address. It should silently return to your prompt. ls /mnt/remote will now reflect the contents of the server’s /usr directory.

It’s really that simple. The most frequent cause of NFS (clients or servers) not working is because the appropriate services are not running. Knowing how to check for them (rpcinfo -p) makes troubleshooting NFS a breeze. Once the file system is mounted, the mount command will show you that /mnt/remote is mounted from the server, and it will also display the mount options.

Mounting many different directories manually is no fun, and you can’t do it as a normal user. On the bright side, NFS file systems can be added to /etc/fstab just like any other file system. An example of our above mount in /etc/fstab looks like: 192.168.0.100:/usr /mnt/remote nfs ro 0 0

A few options worth mentioning here are hard, soft and intr. Mounting “hard” or “soft” has to do with how NFS will deal with the server disappearing suddenly because of a crash or network outage. Soft mounting is dangerous. If a read or write operation fails, the NFS client will report and error to the process that was executing the read or write. Most programs won’t handle this properly, so it is best to simply use the hard mount option.

Hard mounting means that (just like when a disk fails) the process will hang waiting on i/o if a read or write doesn’t process immediately. When the server comes back up, the process will continue normally. This method guarantees data integrity, but can be a bit annoying. Processes will become hung and non-killable unless you also specify the “intr” option, meaning interruptible. Using these recommended options, the fstab entry above will now have “ro,hard,intr” in the options field.

That about covers the basics of NFS. There are many uses for NFS aside from the occasional mounting of directories to copy files.

In an organization with multiple UNIX computers where users login to them all, it may be beneficial to move the user’s home directories onto one file server. You can simply export /home, and then tell all the clients to get /home from the server, and the home directories will be the same no matter which machine users are logged in to. There are other ways to accomplish this as well, such as using autofs.

Article courtesy of EnterpriseNetworkingPlanet.com.

Charlies Schluting is contributor to EnterpriseNetworkPlanet, an Internet.com site.

This article was originally published on August 27, 2008

Was this Article helpful? Yes No
Thank you for your feedback. 0% 0%