[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.
Notices
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.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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.)
The files are in a subdirectory of /opt/greenMonitor/Systems. (/dev/hda3)
No trace of NFS. (unless I don't know what to look for)
apache2 is running. Could it be hiding something?
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
Code:
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.