I have an Ubuntu 12.04 Linux server sharing files via NFSv4. I mount the share on my MacBook Pro running Mac OS X 10.7.5. I have the NFS share set up to automount in Disk Utility with default mount options.

I find that when changes happen on the server in a directory that I have had open in the Finder recently, the Finder does not reflect the changes for a very long time. If I use the terminal to "ls" the same directory, I see the changes. It seems that the Finder is caching directory listings locally, and that this caching is very aggressive.

Closing and reopening the window doesn't help. Force quitting the Finder does not help. Unmounting and remounting the NFS share does not help. Rebooting works, but that's a very blunt instrument.

Has anyone experienced this, and does anyone know of any workarounds? I'm looking to eliminate the caching, so that the Finder does to the VFS layer on every access, or at least shorten the TTL of the cached data.

I've evaluated changing the share to SMB or AFP, but I cannot undertake that and am looking for a way to manually invalidate Finder's cache (or otherwise poke at it) if I can't change Finder's behavior outright.

ETA: This doesn't seem to be an issue any more in Mavericks.

  • Are you looking how to troubleshoot this? Are you looking for someone to suggest different technology. I get the desire for confirmation that others may have experienced this, but what are you looking to do next?
    – bmike
    Commented Apr 30, 2013 at 15:36
  • That's a good question. I don't want to switch to SMB or AFP. Instead, I'm looking for a way to disable the Finder's caching behavior or even a way to manually invalidate that cache.
    – smammy
    Commented May 1, 2013 at 17:28
  • 1
    Unfortunately this isn't an answer, but a confirmation that this problem still persists on Yosemite 10.10.2, connecting to NFS shares on Ubuntu 14.04 LTS. Server shares have these params: rw,nohide,insecure,no_subtree_check,async Client mounts have these params: -resvport,lookupcache=none,nolocks,locallocks,intr,hard,async,wsize=32768,rsize=32768 found that running sudo automount -vc and clicking on/off the folder refreshes it's contents, but this is a bandaid and not a solution. does anyone have any ideas?
    – user113157
    Commented Feb 10, 2015 at 10:07

3 Answers 3


I had the same problem and found a solution here that worked for me:

dscacheutil -flushcache
killall Finder

The man page of dscacheutil says that the -flushcache option should only be used in extreme cases, so there may be risks to this method that I'm not aware of.

  • -flushall doesn't appear to be a valid switch to dscacheutil (on 10.8 at least).
    – smammy
    Commented Feb 24, 2014 at 17:44
  • It should be -flushcache, as edited now. Thanks for pointing it out, @smammy. Commented Feb 25, 2014 at 9:59
  • dscacheutil -flushcache alone (no Finder restart) seems to work for me in Yosemite. The Finder doesn't update on its own, but clicking away from the directory and back does refresh. Thanks for this answer - I've been looking for a solution to this problem for YEARS.
    – GSnyder
    Commented Oct 16, 2014 at 18:33

I had stale files in Finder when I used noac,nonegnamecache in the NFS mount options on Yosemite. Removing those options fixed the problem.

Instead of noac (which is equivalent to actimeo=0), I added actimeo=1 to set the attribute cache timeout to 1 second. I'd prefer if the attribute cache was disabled completely, but this way at least the timeout is low.


I could confirm that there is such a problem, but it's not been consistent for me. I've just checked against SAMBA and NFS shares on the same server, using the same directories and file for the test. I've had an updated view for both shares in Finder, two times in a row. However, I've experienced the problem as described before. Looks like it happens under more specific conditions.

I do not see this problem using other protocols like AFP or SMB, so the obvious workaround would be to alter the server if we can't isolate / affect Finder's caching. In the mean time, you know this might be one solution if no better solution arises here.

You must log in to answer this question.

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