I have several xen guest OSs that get their root file system from NFS. I changed /etc/network/interfaces on some of them (on the nfs server) and then rebooted them. Now I get lots of 'Stale NFS handles' when booting them up. I've rebooted the guest OSs a few times and I'm getting the same problem. How do I fix this?

  • Are the NFS shares mounting correctly - despite the error messages, or not? – Brent Jul 16 '09 at 22:59
  • @Brent Well it's the root filesystem that are being mounted. Hence the VM doesn't boot up, so I can't check that it's being mounted properly. However it does boot part of the way up. Also there are other VMs on the same dom0 using the smae NFS server that work fine. – Rory Jul 17 '09 at 8:57

Did you reboot the NFS server? Did you do some sort of bulk move, rename or deletion of files or directories on the server? Are the clients changing files that other clients are trying to access?

The normal source of a "stale NFS file handle" is files being removed on the server. Especially if a directory is removed. The usual fix is unmounting and remounting the volume, or rebooting the client. With some NFS server implementations, rebooting the server can cause this error, too.

It sounds like there's something else going on here than the usual causes and more detail might be needed.

  • I can't reboot the NFS server, it's in active use. The clients have been rebooted many times now. – Rory Jul 16 '09 at 16:45
  • I'm not suggesting that you reboot the NFS server, I'm asking if you had. Rebooting an NFS server (or restarting the NFS daemon) can cause these kinds of errors in some cases. – freiheit Jul 16 '09 at 17:25
  • No, I haven't restarted the NFS daemon or rebooted the NFS server yet. – Rory Jul 16 '09 at 21:52
  • restarting the NFS server did the job. – Rory Aug 10 '09 at 11:59

I get this alert when I reboot my NFS server without first stopping my NFS clients.

Try umounting and then mounting your NFS partitions (on the clients). If they won't umount, use fuser -m /path/to/nfs to determine which processes are preventing them from umounting.

  • Well I've completly rebooted the client VMs (that are also NFS clients), that should be the same as an NFS umount. And still the problem exists. – Rory Jul 16 '09 at 16:58
  • You would think so. – Brent Jul 16 '09 at 19:23
  • So if ti shutdown the vm that's using that nfs share, what more can I do to 'unmount' it? – Rory Jul 16 '09 at 21:52
  • I was thinking of actually running "umount /path/to/nfs", and then "mount /path/to/nfs". I don't know if there are state files that would be removed/reset by doing this explicitly, that would not be done via a reboot - unless for some reason the "umount" command failed during the reboot - hence skipping that step. This would make that evident. – Brent Jul 16 '09 at 22:57

see http://sysunconfig.net/unixtips/stale_nfs.txt

this usually happens when the network link between the NFS client (your VM) and the NFS server goes missing (or you experience packet loss)

try pinging the NFS server from the VMs and VMs from the NFS to rule the connectivity out

  • The computer running the VMs is the same as the NFS server! So there really really shouldn't be any network problems – Rory Jul 16 '09 at 16:58
  • 1
    "shouldn't" != "isn't". Once you've ruled out the likely things, check for the unlikely, then once you rule those out, rule out the impossible. – freiheit Jul 16 '09 at 17:07
  • +1 for the comment..shades of Sherlock Holmes and cheek..:-P – Software Mechanic May 22 '11 at 17:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.