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.)

Written on 11 July 2009.
« An unpleasant surprise about ZFS scrubbing in Solaris 10 U6
A brief history of NFS server access restrictions »

Page tools: View Source, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sat Jul 11 02:01:21 2009
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.