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.

  • 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
    Commented Oct 5, 2010 at 21:09

4 Answers 4


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.


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.


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


When exports are messed up and you need to clear and load fresh ones, fix it from NetApp Exports first, then from the client run "Service nfslock restart" on the linux nodes.

Hope this helps someone in the future.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .