When our main NFS server goes offline, all clients which had a share mounted are affected in the following way:

1. `df` does not work (times out)
2. `lsof` does not work (times out)
3. I cannot unmount the share (umount times out)
4. I cannot restart the client PC, the shutdown process gets stuck 
   while trying to umount the dead NFS share: 
   `nfs server not responding still trying`
5. hard reboot (reset) works, but while booting the client PC gets 
   stuck while trying to mount the NFS share

Now I know how to solve the problem nr. 5. I can change the entry in fstab to noauto. But what about the other problems? Does NFS client have no intelligence to stop waiting for a dead NFS server? Why does it wait indefinetly? Can I somewhere set a timeout, so that whatever happens, after x seconds he gives up trying?


3 Answers 3


Yes this is the nature of NFS. The clients will wait indefinitely for the NFS resource to come back. Believe it or not it's designed to work this way!


The better approach would probably be to use a tool such as autofs to automount the NFS shares as needed, rather than keep them mounted indefinitely.

Using just NFS

As @Patrick pointed out in the comments you can curtail this behavior by using the soft option when mounting NFS shares.

excerpt from source: http://www.tldp.org/HOWTO/NFS-HOWTO/client.html


If a file request fails, the NFS client will report an error to the process on the client machine requesting the file access. Some programs can handle this with composure, most won't. We do not recommend using this setting; it is a recipe for corrupted files and lost data. You should especially not use this for mail disks --- if you value your mail, that is.


The program accessing a file on a NFS mounted file system will hang when the server crashes. The process cannot be interrupted or killed (except by a "sure kill") unless you also specify intr. When the NFS server is back online the program will continue undisturbed from where it was. We recommend using hard,intr on all NFS mounted file systems.

In your /etc/fstab file

   # device             mountpoint  fs-type    options    dump fsckord
   master.foo.com:/home  /mnt/home   nfs      rw,soft  0     0

( i know it is old post but ... )

umount the mountpoint 'lazy':

umount -l -f /mount/piont

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

This will unmount the stale NFS mountpoint and serveroperation will not be hindered by the stale NFS mount.

Be adviced that you need to manually mount the NFS share when is comes up again


I noticed something when trying to unmount directories for NFS servers that go offline. My first instinct is to unmount lowest subdirectories first and then work my way up to the top of the directory tree. However, unmounting subdirectories by using --force and --lazy failed and resulted in a long timeout. What finally worked for me was when I used --force and --lazy at the top level, as in:

umount --lazy --force /net/machine

Don't first try to unmount the lower directories, such as:

umount --lazy --force /net/machine/subdir

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .