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.
Required to be active in the running kernel.
File systems --→ Network File Systems
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.
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
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:
Possibly necessary for mounting NFS as a client:
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
-rw arguments if you like (
default). Another mount example:
mount -o ro 192.168.44.4:/mnt/2.2/suse ./vulture
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:
What nfs mounts are being used by a client? You can look at
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
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
the missing NFS volume with the
-f option. Of course remove it from
fstab too if needed. Problem solved.
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
nethogs? That’s a nice program too. Also
Check out this fine analysis of NFS4.1 on Linux. Check the references for benchmark utilities.
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
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.