Unmount a nfs mount where the nfs server has disappeared

Solution 1:

Assuming Linux:

umount -f -l /mnt/myfolder

Will sort of fix the problem:

-f Force unmount (in case of an unreachable NFS system). (Requires kernel 2.1.116 or later.)

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

-f also exists on Solaris and AIX.

Solution 2:

Elaborating upon the hint given by David Pashley,

unless "umount -l" solves your problem, you can set up a fake server with the same address as the one that has gone away - but you don't actually have to set up a new sever or anything. The easiest way out of the blocking/hung umount situation is to set up a local alias IP interface, as follows:

ifconfig eth0:nfstmp 11.22.33.44 netmask 255.255.255.255
umount -l /mnt/deadnfsmount    # -l or -f or whichever that gets the job done
ifconfig eth0:nfstmp down

(obviously 11.22.33.44 being the (former) IP address of the (now dead) NFS server)


Solution 3:

It might be wise to add the intr option to any /etc/fstab entries that might end up hanging or crashing. If you don't use the soft or intr options, then when the server hosting the NFS files goes down, the server on which the files are mounted (the client) may hang when booting up.

According to man 5 nfs:

soft / hard
Determines the recovery behavior of the NFS client after an NFS request times out. If neither option is specified (or if the hard option is specified), NFS requests are retried indefinitely. If the soft option is specified, then the NFS client fails an NFS request after retrans retransmissions have been sent, causing the NFS client to return an error to the calling application.

... and then it goes on to say intr is preferred over soft, but it has the similar effect of preventing hanging.


Solution 4:

umount -f /mnt/myfolder should solve this. See the umount manpage.