I recently came across this slightly bizarre issue.  I was trying to mount a NFS share from one server to another server, using very loose permissions (I was basically sharing a DVD to a machine which had no DVD-ROM drive).

So, what was happening?  Well, basically nothing.  On the NFS server (the machine with the DVD exported) I ran tcp dump to see what traffic was being received (the server was IP 192.168.10.200):

No output was displayed when I was trying to mount the share on the client. None at all.  Well, almost none.  The one bit of output that got me wondering was a broadcast packet which was received from the client.

   10:14:45.651572 IP 192.168.10.1 > 192.168.10.255 arp who has 192.168.10.201 tell 192.168.10.1

The IP address 192.168.10.201 was a typo made by me the day before.  I’d meant to type in .200 in my mount string.  My incorrect mount command thus read:
 
  # mount -t nfs 192.168.10.201:/mnt/share /mnt/dvd

It seemed strange that an incorrect mount command that I’d typed in yesterday (and then hit CTRL-C to)might still be working in the background.

Back to the client, I realised that perhaps the mount command worked in a queue/serial-like way.  Therefore, each mount command would have to complete – either successfully or not, so long as it finally returned – before the next one was attempted.  Checking out this theory, I investigated local processes:

Sure enough, there were lots of mount entries pointing to the wrong IP address.  These were all my attempts to mount a non-existing server’s share to a local directory.  Dumb mistake, eh.  Still, CTRL-C didn’t cancel the mount request, which continued to run in the background.

The easiest solution was to reboot the server, but in situations where that’s not practical, killing the rogue processes should suffice.