What can go wrong in making NFS mounts
July 11, 2009
Now that we know what goes on in NFS mounts, we can see that there are any number of moving parts that can go wrong:
- the RPC portmapper refuses to talk to you (possibly because a firewall gets in the way, possibly because it has been set up with tcpwrappers based restrictions).
- the NFS mount daemon refuses to talk to you, possibly because it
usually insists that clients use a reserved port, or there could be another firewall
problem since it uses a different port than the portmapper.
- the NFS mount daemon thinks that you don't have sufficient permissions,
so it refuses to give you an NFS filehandle.
- the kernel NFS server refuses to talk to you, possibly because of
yet another firewall issue.
- the NFS filehandle you get back is broken.
- the kernel NFS server refuses to accept the filehandle that the NFS
mount daemon gave you. This is especially fun, because sometimes
mount
will claim that the filesystem was successfully mounted but any attempt to do anything to it will fail or hang.
Most versions of mount
will at least give you different error messages
in the various sorts of cases, generally of increasing peculiarity and
opaqueness as you move down this list.
(Thus, I have seen mount
report 'invalid superblock' on NFS mount
attempts.)
(One comment.)
Written on 11 July 2009.
|
|