Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Here's my set up: One NFS Server machine (v4), several NFS client machines.

When a client machine write files to the NFS mount, the other clients see the new content instantly : no problem.

But, when the server machine modify the content of the file, this new content is not shown on the client until I do a ls of the directory from the client.

I'm absolutely stumped on this inconsistency...any help would be greatly appreciated!

Infos :

  • nfs 1.2.3-r1 on both client and server
  • acregmin, acregmax, acdirmin, acdirmax, lookupcache : default values
share|improve this question
Can you do a little experiment for more info?: Do an ls -i on the client before editing the file on the server, then again after. See if the numbers change. If they do its because the server is replacing the file and the client doesnt notice this until it rescans the directory. If so try setting the mount option lookupcache=none and see if the behavior changes. – Patrick Apr 19 '12 at 1:39
sorry for the delay. The inode effectively changes. I've added the lookupcache option, it seems to work. I will check again tomorrow. – numberxiii Apr 24 '12 at 16:39

Adding as an answer based on your comment.
The solution is to add lookupcache=none to your nfs mount options.

What happens is that the first time your client reads the file it does a NFS lookup to get the NFS fileid. It then caches the NFS fileid, and when you go back to open the file, it uses the cache. Normally this isnt a problem as when the file is updated its fileid stays the same. But for some reason the old file is being removed, and a new one is created (or renamed, or something to where its not the same file).
Now normally this isnt a problem either as when your client tries to open a fileid which isnt there, it will get an error from the server and do another lookup to get the new fileid. But for some reason the NFS server is letting the client open that old fileid. Perhaps another client has the file open and so its not being deleted yet, I dont know.

In any case the way to solve it is to tell the client to always do an nfslookup before opening a file by using the nfs mount option lookupcache=none. The downside to this is that it can be expensive if you are frequently opening files since it adds more traffic to the NFS server.

share|improve this answer
Thanks for your explication. On the NFS server, the stack of the exported directory is DRBD/LVM/ext4. May be it's causing the "bug". I have the problem on several client, but not on some others... I will redo all my tests and tell you if all is going well with this option. – numberxiii Apr 24 '12 at 21:37

Change the mount option to hard,intr. i think the default may be soft in your system. this will help.

share|improve this answer
unfortunately, adding these mount options didn't change anything :( – numberxiii Apr 18 '12 at 8:17
For my first test, I do a remount. Then I've done a test from another client, with a clean mount. The problem seems to be corrected : we wait 30s to see the new content – numberxiii Apr 18 '12 at 9:12
I've build a new client (vm) to check : no problem with the content ! – numberxiii Apr 18 '12 at 15:44
@johnshen64 why do you think hard would solve the issue? Hard/soft only matter when it comes to connection interruption, has nothing to do with caching. – Patrick Apr 19 '12 at 12:55

Your Answer


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.