3

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?

2
  • Are the NFS shares mounting correctly - despite the error messages, or not?
    – Brent
    Jul 16, 2009 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. Jul 17, 2009 at 8:57

3 Answers 3

2

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.

4
  • I can't reboot the NFS server, it's in active use. The clients have been rebooted many times now. Jul 16, 2009 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, 2009 at 17:25
  • No, I haven't restarted the NFS daemon or rebooted the NFS server yet. Jul 16, 2009 at 21:52
  • restarting the NFS server did the job. Aug 10, 2009 at 11:59
1

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.

4
  • 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. Jul 16, 2009 at 16:58
  • You would think so.
    – Brent
    Jul 16, 2009 at 19:23
  • So if ti shutdown the vm that's using that nfs share, what more can I do to 'unmount' it? Jul 16, 2009 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, 2009 at 22:57
0

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

3
  • The computer running the VMs is the same as the NFS server! So there really really shouldn't be any network problems Jul 16, 2009 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, 2009 at 17:07
  • +1 for the comment..shades of Sherlock Holmes and cheek..:-P May 22, 2011 at 17:56

You must log in to answer this question.

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