Setting up NFS

Considering how powerful NFS is and the flexibility it gives you it is amazingly simple to set up. I expected it to be on a par with setting up Samba which can be a complete nightmare. Typically when setting up Samba one would use Swat or another configuration tool. With NFS set us is as easy as entering the paths you want exported into /etc/exports and making sure the correct packages are installed.

There are two implimentations of NFS one runs in kernel space (nfs-kernel-server) the other in user space (nfs-user-server). The kernel space implimentation is faster and more stable but if something goes wrong it could bring your box down. In reality the kernel space NFS implimentation very rarely fails. I have been running it for years (and on at least one occasion for 150 days straight) and have had it fail only a couple of times. The times it did fail it simply needed restarting. In fact the only way I have even managed to get it to make a noise is when I had a box with a network card that was on the way out. The port on the card was bad which caused it to repeatedly drop and re-aquire the network sometimes several times a minute. After a few hours of that NFS would sometimes start to refuse new connections.

As well as the server you will need portmap. Fortunatly if you chose NFS when you first installed the server you will have all the required packages already installed, configured and running.

One important point to remember when setting up NFS is to make sure that the user id (uid) of the user on the server matches the uid of the user on the local machine. NFS has no way of mapping "fred" on the local machine to "fred" on the server other than by relying on the uids being the same. Typically when you create a user the uid given is just the next one available but you can specify it explicitly.

Once you have made the required entries in /etc/exports you need to tell the NFS server about them. Typically I restart all three required utilities (portmap, nfs-kernel-server and nfs-common) as it is generally the best way to make sure everything is working correctly. See the section below on restarting NFS.

Exporting Directories

As mentioned above there isn't anywhere nearly as much work involved in exporting directories under NFS as there is under Samba. Having said that though you also don't have the same sort of control. Essentially you have the same control a typical Linux filesystem would give you (owner, group and other access rights). In fact 99.9% of the time you can't tell the difference between an NFS mount and a regular bit of the file system. One key difference is that root doesn't (generally) have the ability to perform any action in the mounted directory. This effect is called root squash (root is squashed down to a regular user) and is needed so that people can be root on their own local machine but not affect other users files on a mounted filesystem. Root squashing can be turned off but I would advise you leave it on even if you only run a small network if for no other reason than it's a good way to avoid rm -rf accidents.

To export a directory fire up your favorite text editor and make an entory in /etc/exports. A typical exports file might look something like this:


This exports two directories (/data and /home) to the local network. The first one is a general scratch drive for shared information and squashs the group to gid 50 which is typically staff. The second exports the users home directory so they can use the same home directory whichever machine they are using.

Restarting NFS After An Upgrade

To (re)start NFS you have start the applications in this order or you will run into problems with one thing relying on another before it will start cleanly:

/etc/init.d/portmap start
/etc/init.d/nfs-kernel-server start
/etc/init.d/nfs-common start

You can shutdown the services in any other but I normally do it in reverse order (starting with nfs-common).

What NFS Components are Running

Information about what NFS commponents are running can be gathered with the command "rpcinfo -p" which should give output looking something like this:

program vers proto   port
    100000    2   tcp    111  portmapper
    100000    2   udp    111  portmapper
    100003    2   udp   2049  nfs
    100003    3   udp   2049  nfs
    100003    4   udp   2049  nfs
    100003    2   tcp   2049  nfs
    100003    3   tcp   2049  nfs
    100003    4   tcp   2049  nfs
    100021    1   udp  39666  nlockmgr
    100021    3   udp  39666  nlockmgr
    100021    4   udp  39666  nlockmgr
    100021    1   tcp  49938  nlockmgr
    100021    3   tcp  49938  nlockmgr
    100021    4   tcp  49938  nlockmgr
    100005    1   udp    899  mountd
    100005    1   tcp    902  mountd
    100005    2   udp    899  mountd
    100005    2   tcp    902  mountd
    100005    3   udp    899  mountd
    100005    3   tcp    902  mountd
    100024    1   udp   1017  status
    100024    1   tcp   1020  status

Mounting NFS Drives

To mount an NFS drive on another machine locally automatically at boot time you need to add a line like this to /etc/fstab:

<server>:<drive> <mount-point> nfs <options> 0 0

Where server is the name of the machine hosting the drive. Drive is the same as the name of the drive in the servers exports file. Mount-point is the local mount point (don't forget to make a directory at the desired mount point) and options are the options you want (typically just rw).

You can also mount an NFS share manually quite simply using the mount command like this:

mount -t nfs <server>:<drive> <mount-point>

Finding Out What is Exported

The quitest way to find out what is exported on a particular machine is just "cat /etc/exports"

Possible Problems with NFS

If you don't have rpc.statd running on the server (it's started by nfs-common) I think you will see error messages like those shown below (I haven't tested this but when I made sure statd was running on both server and clients the message stopped). The system will however work correctly without statd running on the server although it will be a little slower than normal.

Apr  6 11:37:42 foo kernel: nsm_mon_unmon: rpc failed, status=-13
Apr  6 11:37:42 foo kernel: lockd: cannot monitor