Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

We have a bunch of Linux boxes mounting NFS shares off a NetApp filer. From time to time, I will flub some part of the export configuration. Typo on one of the allowed hosts, incorrect IP address, etc, etc. No worries, this is usually done on a test system, or with brand new exports that aren't yet in production.

However, I've found that once I've been denied permission to mount something from a Linux machine, the failure gets cached for as long as a day. I will correct the problem that was blocking the mount, re-export on the NetApp, and still not be able to mount the share. I'm pretty sure this caching is done at the NetApp side. It normally ages out after a day or so, but it really sucks having to wait until tomorrow to mount a share.

I've tried exportfs -f on the NetApp, as well as dns flush. (I found both suggestions via Google) However, neither one works.

I would sell my soul if someone could help out with a command/pagan ritual that would clear up this cache issue.

share|improve this question
    
I don't have an answer but was curious about some details... Do you use NIS/YP and/or other directory services? If using NIS/YP, do you use netgroups? Do you specify the data on the export line by hostname or IPv4 number? Just for curiousity anything different if you use "exportfs -a" for the command? What does a typical mount line look like that you use? –  mdpc Oct 5 '10 at 21:09

3 Answers 3

You can run "exportfs" without any options to verify that your export is loaded correctly. If it's in the /etc/exports file but not loaded, you might need to "exportfs -a" or "exportfs -r" to reexport it. From there you can check the access cache with "exportfs -c" or flush it with "exportfs -f".

The next thing to check on the controller is that your client is reachable & resolvable. Assuming you have pings enabled on your network you can "ping -s hostname" from the NetApp controller. I'd check both the hostname and ip address.

Past that, you'll probably need to look at your client.

share|improve this answer

Well, that shouldn't really happen, assuming you are reloading the exports correctly (ie. not just updating /etc/exports. First thing to do is turn on the logging option for mount requests:

options nfs.mountd.trace on

Then check /etc/messages and see what you see. If it's not obvious, update with the output and we can look further. There are too many other factors in play here to try to diagnose without more info.

share|improve this answer

usually flush -f works but today I had to include the -n as well (OnTap 7.3.7P1) - observed results with options nfs.response.trace and nfs.mountd.trace

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.