[SOLVED] Stale NFS handle on embedded system that does not have NFS running
Linux - Embedded & Single-board computerThis forum is for the discussion of Linux on both embedded devices and single-board computers (such as the Raspberry Pi, BeagleBoard and PandaBoard). Discussions involving Arduino, plug computers and other micro-controller like devices are also welcome.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
Stale NFS handle on embedded system that does not have NFS running
I have a little box running Voyager Linux that monitors my power system. Its disk (16GB CF, actually) is getting full, so I deleted a lot of older files (and some I should *not* have). I was logged in via ssh, and was in the directory containing the files.
Now 'ls' gives a clean listing, but 'ls -al' gives masses of
cannot access xxxxx: stale NFS handle
There do not appear to be any nfs related processes running.
Are you in /net by any chance? If so you don't need to clean up anything there and should leave it alone - it is a quick reference to all nfs mounts available whether you've actually mounted them or not.
If you run "cat /etc/mtab" what does it show? Any nfs entries?
Do /etc/fstab or /etc/auto* files have any nfs mount entries (other than /net)?
You can try remounting whatever filesystem is giving the stale NFS mounts then cleanly unmount it. If the source hosts of the nfs mount is not available the only way I know to clear stale NFS mounts would be to reboot the system complaining about them.
Prior to doing a reboot you'd want to be sure you didn't delete any key files needed for boot. (Since you said you removed some files you shouldn't have.)
When you do the ls -al when it says cannot access "xxxxxx" is that something literal or did you hide the name of a system there? Does it show you the name of the file? Is the file or the subdirectory perhaps a symbolic link? For automatount stuff it often will be.
Interestingly what appears to be your PS1 prompt "greenpc:/opt/greenMonitor/Systems/mySystem#" is in the same form as an NFS mount. The commands you're typing are while logged into system, greenpc, itself correct?
I wonder if your system is somehow interpreting the PS1 prompt or other variable you've set with that syntax and thinking it is trying to do an NFS traversal of server greenpc even though you're already on greenpc?
What happens if you type "pwd" in the above directory?
What is the output of:
ls -ld /opt
ls -ld /opt/greenMonitor
ls -ld /opt/greenMonitor/Systems
ls -ld /opt/greenMonitor/mySystem (The # is the end of your PS1 prompt rather than part of the directory name, correct?)
I stopped all processes that might use files on /dev/hda3, unmounted it, and ran fsck (several times).
The result was tens of thousands of
DATA: Entry 'gmStatus2692987059952628010gms' in /mySystem (105665) has deleted/unused inode 164434. CLEARED.
It appears that there was one for each stale NFS handle. There were a few other problems fixed, like files being links to directories, and then tens of thousands of inodes with count 2 that should be 1.
After holding the Enter key down for several hours all problems appear to be fixed.
Something in the boot process is mounting /dev/hda3 under /opt/greenMonitor/Systems. While I was working on it I mounted it in a temporary directory, and the only contents were lost+found and mySystem.
Deleting files from lost+found worked without any problems. I suspect a bug in the Compact Flash driver is the cause of the problems. I will check with the manufacturer to see if others have had the problem.