I had a stale NFS filehandle today on an old Solaris 8 server, here is how I resolved the problem.
First, here is a brief overview of NFS filehandles.
NFS Clients will not be able to access an NFS share if the NFS filehandle has changed, making the filehandle stale if the directory was removed or replaced or renamed, making it unaccessible on the NFS server.
With the issue I experienced, none of the usual situations above applied.
The inode remained the same, and therefore the NFS generated filehandles will remain the same.
On the NFS Server I exported a filesystem, say called /data/korea/seoul, deported a VxVM diskgroup containing this filesystem which is NFS shared, performed some work and then re-imported the VxVM diskgroup, started the volume and then mounted the filesystem.
When I deported the VxVM diskgroup, I did’nt know that the filesystem was shared over NFS.
This is what I saw, and how I fixed it.
NFS Client – with auto-mounting configured
$ cd /dat/korea ksh: /dat/korea: permission denied $ ypcat -k auto.dat | grep korea korea -fstype=nfs,rw,soft nfsserver:/data/korea/seoul
# unshare /data/korea/seoul # share -F nfs -o rw -d "my description here" /data/korea/seoul
$ cd /dat/korea $
If that fails, restart the NFS daemon, if possible depending upon other NFS exports.
Use DTrace (if Solaris 10) to see what’s going on.
And if that fails, you need to restart the system which hosts the NFS server.