I am by no means an expert on NFS. I border on being NFS-literate, in fact. But I excel at encountering errors. Here, I will attempt to document some of the ones I’ve figured out how to fix / work around.
mount.nfs: access denied by server
This is the error that led to the joking “one weird trick” (referencing those spammy ads) title of this post.
I keep running into errors like this:
$ sudo mount -t nfs winterfell:/home/j /mnt/j
mount.nfs: access denied by server while mounting winterfell:/home/j
I think the error can be caused by a number of things. From the client, check that showmount -e winterfell (where winterfell, of course, is the name of the server you’re trying to mount a volume from) (a) returns anything at all (meaning you can at least reach the server), (b) lists the share matching the one you’re trying to mount, and (c) has an IP mask that matches the one you’re connecting from.
If (a) fails, check iptables (make sure port 2049, at least, is open). If (b) or (c) fails, fix it in /etc/exports, and reload the config with exportfs -r.
But if everything above looks normal, but you can’t actually mount the share, it’s probably this: NFSv4 appears to require functional reverse DNS or it will fail without telling you much about what’s going on. I’m still a bit in the dark on the details. You might try using the IP instead of a hostname. If that doesn’t work, the “one weird trick” is to fall back to NFSv3 (or even NFSv2, but don’t), which doesn’t do this. Something like this:
sudo mount -t nfs -o nfsvers=3 winterfell:/home/j /mnt/j
If that succeeds, you’ll know the problem.
mount_nfs: can’t mount $share from $hostname onto $mountpoint: Operation not permitted
I keep getting this one when trying to mount things on a Mac client.
This is fixed by adding the -o resvport flag to your mount command, e.g.:
sudo mount -t nfs -o resvport winterfell:/home/j /mnt/j
IIUC, what is happening here is that the server is requiring that clients connect from a reserved (<1024) port (which only superusers can do), but the Mac client doesn’t do that by default. -o resvport tells it to bind to a reserved port, and you’re golden.
Hopefully someone else will find these tips useful. (That “someone else” may be me in six months’ time…)
Another one:
If you have an NFS mount that’s seen a network failure and can’t be unmounted, you might find that even the
-f(force) option toumountdoesn’t work.Check out the
-loption, though (on Linux, at least):-l, --lazy Lazy unmount. Detach the filesystem from the filesystem hierarchy now, and cleanup all references to the filesystem as soon as it is not busy anymore. (Requires kernel 2.4.11 or later.)umount -fl /mnt/some-nfs-sharehas worked well for me.Thanks for your handy trick. I was not having exactly the same problem, but close enough for me to try using nfsv3 — and it worked. ( big thanks !!! )
I was commissioning a donated server ( A Dell 2950, running Debian 7.5 ) as the master file server for everyone’s home directory at our school. Our network is a real mess, from gigabit to dodgy wireless to connect to all the client machines. What was happening with nfsV4 was the occasional lockup of an nfs read or write, notably on the poor quality links. A tcpdump showed strange retries, as if there was a strange deadlock when using nfsV4 flooding the server with retry requests from some machines.
I made all the clients mount with nsfvers=3 in /etc/fstab and the problem went away.