NFS Overview

Here are some notes on making NFS work. In case you just joined the program, NFS is Networked File System and it is basically a networking protocol that lets the OS think there is some normal file system, just like the one on the hard drive, that is really somewhere totally different. In other words, a filesystem that has to be networked. Unfortunately, there are some annoying little things to take care of before it all works right. These are in two categories 1. configuration and 2. turning it on and off when you need it once it is configured. Once it’s configured, it’s just like any filesystem (like the harddrive, a cd, a floppy, whatever). Of course you have to make the remote data capable of "serving" its goods as a NFS server. And then you need to mount that from your "local" machine just like you’d mount anything else.

Getting NFS

Debian 2020 -

apt install nfs-common

Gentoo NFS Documentation -

emerge net-fs/nfs-utils

Kernel Support

Required to be active in the running kernel.

  • Dnotify support

  • File systems --→ Network File Systems

Configuration

Step 1- the /etc/exports file is very important. man exports helps out a lot. Here’s all that’s needed for a service to cardinal and pelican.

/       cardinal(rw,no_root_squash) pelican(rw,no_root_squash)

This example shows the /files/admin directory being made available read only to a specific machine with a local IP number.

/files/admin            192.168.30.8(ro,sync,no_subtree_check)

The / says that it’s dishing out the root directory on down (a Linux special feature apparently not often found on all Unices) The hostname is easy enough. The rw is read/write as opposed to ro which is read only. The no_root_squash is so that the NFS server doesn’t laugh at the fact that you’d like to be root on a foreign terminal. If you show up with a UID and GID of 0 and 0, it defaults to 65###, some big #, on the mounted system. That is called squashing. To prevent exalted status from being squashed, you need to be explicit about it on the server side before a mount is attempted. (by the way, GID is group ID and UID is user ID and if they are both 0, then you have won an all expenses paid trip to be the root user. Don’t believe me, do this: cat /etc/passwd and look at the 3rd and 4th fields.)

Step 2- Reset the serving daemons. This is where my book was woefully incomplete. It said to deal with the rpc.nfsd, but it totally omitted the equally important rpc.mountd. BOTH of the daemons use the /etc/exports file and if you update it, you must restart these daemons.

ps -ax | grep "rpc."
kill -HUP #OFnfsd ; kill -HUP #OFmountd

(#OFnfsd is the process number) These days, normal distributions have this all set up nicely and you can just turn NFS on by using normal init scripts. Necessary for serving NFS:

/etc/init.d/nfs start

Possibly necessary for mounting NFS as a client:

/etc/init.d/nfsmount start

Step 3- Try to mount the server from the client machine. For example, after setting up /etc/exports and resetting the daemons on vulture, try to do this from cardinal:

mount vulture:/ /mnt/vulture

You can throw in some -ro or -rw arguments if you like (-rw is default). Another mount example:

mount -o ro 192.168.44.4:/mnt/2.2/suse ./vulture

Troubleshooting

What does the client see from the NFS server? Try this to find out:

showmount -e files.xed.ch

This tells you a lot. Maybe too much for security conscious people.

What kind of NFS requests are transpiring on the server? Check it out with:

nfsstat -s

What nfs mounts are being used by a client? You can look at df or try this:

nfsstat -m

Stale File Handle

What if you’ve been messing around with the NFS server (typical) or some other bad thing had happened (network outage?) and you get the dreaded "Stale file handle"?

[root@ws1-ablab ~]# ls -al /mynfsdir
ls: /mynfsdir/: Stale file handle
ls: cannot open directory /mynfsdir/: Stale file handle

Being very patient can often work wonders. If that is not working I have had luck with exportfs -f on the server. The -f stands for "flush". Although rebooting seems the ultimate solution, it may not actually work.

I’ve also had situations where I’m no longer using an exported volume but the client is still configured to be mounted to it. This shows the stale file handle in commands like df. The cure here is to umount the missing NFS volume with the -f option. Of course remove it from fstab too if needed. Problem solved.

Performance Tuning

Does it seem slow? Try watching it with iptraf. Set the update interval to 1 sec to not overwhelm the network traffic with your own iptraf feedback loop. Or figure out filters which have not yet worked for me.

How about nethogs? That’s a nice program too. Also iftop. Maybe dstat or slurm.

Check out this fine analysis of NFS4.1 on Linux. Check the references for benchmark utilities.

Permission Problems

This is almost always a "root squash" issue. The default behavior of an NFS server is to not honor the root user ID (which is 0). So if you try to sudo cp /local/file /nfsmounted/ you will be trying to write to the NFS server as root. It does not allow that by default. If it did, then users with physical control of their own client boxes could just become root and then peek into and change everyone else’s data. This is not normally a good thing. Normally only the proper UIDs can use the corresponding data on the server. Of course it’s also easy to spoof these too, so it’s not an especially strong form of protection. But short of a very deliberate attempt to cause trouble, this scheme will prevent users from accidentally wiping out the whole file system with a dumb sudo rm -r /. If they did that, they’d wipe out their local system only.