LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Networking (https://www.linuxquestions.org/questions/linux-networking-3/)
-   -   Stale NFS handle - how to recover w/o reboot? (https://www.linuxquestions.org/questions/linux-networking-3/stale-nfs-handle-how-to-recover-w-o-reboot-255385/)

BrianK 11-15-2004 11:23 PM

Stale NFS handle - how to recover w/o reboot?
 
I powered off my NFS file server without unmounting all the nfs clients first. Now that it's back on, my nfs clients get a "Stale nfs handle" on the nfs share. I can get it back by rebooting them all (the clients), but is there a way to get it working again without rebooting?

I tried unmounting & remounting the nfs share, but I can't unmount, I get "device is busy"

I also tried stopping portmap & nfs on the client & then restarting them. no luck.

ideas?

I know I can always reboot, but I'd rather not.

Thanks.

eflester 11-16-2004 12:19 AM

When I try to umount, I almost always have to use the -l option (that's an L) or I get the "busy" signal. And although you probably already know this, I always forget: you can't be in the directory you're trying to unmount. Go up a level or two, and try umount-l.

Also, you can try just restarting the nfs service on the clients and/or server. Not knowing what distro you are using I can't be specific, but often this can be done as simply as #service nfs restart.

thrombomodulin 08-10-2005 09:37 AM

NFS stale file handle on server reboot
 
Hello,

I also find that when a server exporting a NFS directory is rebooted, that any client that has this directory mounted will normally never recover. The error message reported on the client is "Stale NFS file handle". Even when all files are closed, the command 'umount -l' or 'umount -f' will not unmount the directory (device busy error).

*** How can this be solved without rebooting the client? ***

This occurs when exported directories are RAID0 arrays that have two (or more) SCSI disks. However, when I tested this using another machine exporting from a IDE non-raid disk the client does recover. In the case of the RAID0 array, the 'fsid' export option was used, but nevertheless failure still occurs when the sever reboots.

FYI: The OS is redhat linux 9.

Does anyone have any ideas?

Thanks,

eflester 08-10-2005 12:27 PM

Ideas I have, answers maybe. Firstly, refer to the post before yours, from me. Forgive me for mentioning this but be sure you are not doing umount when you are "in" the directory where the export is mounted. Secondly, as I mentioned in that post, you can simply restart the nfs service; you don't have to reboot the computer. It seems that I've sometimes needed to restart the service on both server and client, and the order in which this is done may be important. I hope this helps.

thrombomodulin 08-13-2005 09:51 PM

nfs server reboot
 
Thanks for your reply. We've tried this ready: both restarting NFS and, of course, the umount command was not executed from the mounted directory.

Even if restarting the NFS server worked, it would be an undesireable solution as it may cause problems with other mounted directories on the same server.

Best Regards,

Thromb,

eflester 08-13-2005 10:14 PM

I see.

Well, let me dump the rest of my experience with NFS here. It's not much, but it might help.

I once had a really strange problem with an NFS mount that would only happen sometimes, and when it happened the only thing that seemed to fix it was that undesirable of undesirables, the reboot. It's a long story, but I won't bore you with all of it. Just what I discovered, and what fixed the strange behavior: a new NIC.

I know that doesn't seem likely, it didn't seem likely to me at the time, but I pursued that problem for about a year and when I changed the NIC in the client PC, no more strange NFS behavior.
Go figure.

Best of luck!

kakubei 08-28-2008 06:29 AM

restart NFS service on the server
 
If nothing else works, you can try restarting the NFS service on the server. I know you stated this is not desirable because it could cause problems with the other mounts, especially if a client is writing data at the time of the restart.

HOWEVER, there should not be any problem with restarting the NFS service on the server and the other clients should not lose any data. The time it takes to restart the NFS service is quite negligible and you should be ok. We have had to do this sometimes on a production server and haven't had too many problems.

It is strange though that you cannot solve it using umount and then mount again. This might happen because there is an rpcd connection to stale NFS mounts in which case restarting the rpc daemons (whichever ones you are using, if Fedora-based, use "chkconfig --list |grep rpc" without the quotes, to find out what services have rpc in them) might do the trick.

Hope this helps.

senyahnoj 09-11-2009 10:35 AM

umount -f
 
I get this a lot with SVN working copies on an NFS share. The only thing I can get to work is detailed here:

http://www.cyberciti.biz/tips/nfs-st...-solution.html

i.e. umount the share with the -f option then mount it again

snaveen58 05-16-2012 11:06 PM

Quote:

Originally Posted by BrianK (Post 1295728)
I powered off my NFS file server without unmounting all the nfs clients first. Now that it's back on, my nfs clients get a "Stale nfs handle" on the nfs share. I can get it back by rebooting them all (the clients), but is there a way to get it working again without rebooting?

I tried unmounting & remounting the nfs share, but I can't unmount, I get "device is busy"

I also tried stopping portmap & nfs on the client & then restarting them. no luck.

ideas?

I know I can always reboot, but I'd rather not.

Thanks.

1> At server side in /etc/exports add FSID some number(0-65535) per NFS share.
2> Now remount all your NFS share at client.
3> Reboot NFS server and check out. All the shares will be accessible at client after successful reboot of NFS server.


All times are GMT -5. The time now is 12:42 AM.