== What can go wrong in making NFS mounts

Now that we know [[what goes on in NFS mounts ../unix/NFSMounts]], 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
  ../unix/NFSReservedPorts]], 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.)