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

Similar to Concurrent FTP access.

How is concurrent file access handled for NFS? Say that one client is updating/overwriting a file on a NFS server, and a process on the server is reading that same file directly from the file system at the same time. Is there some sort of atomic handling of file read/write in NFS/Linux or do I have to work with tmp files to ensure data consistency?

I'm worried that the process reading the file will get corrupt data.

share|improve this question
up vote 3 down vote accepted

Specific daemons (rpc.statd and rpc.lockd) help with OS-level locking, but in general, you don't want to rely on it, and as Josip writes, many Unix applications implement their own application-level locking.

If you're going to have write contention on files, standard practice is not to serve such files over NFS in the first place.

share|improve this answer
So FTP is better? – Kristian Sep 1 '09 at 12:16
Who said anything about FTP? Files that are potentially modified by multiple people at similar times are best controlled by a Revision/Document control system. NFS isn't going to be any better/worse then CIFS/FTP/SFTP, it's usually up to the app to "lock" files or otherwise notify users that someone else has their dirty little fingers in a file. – prestomation Sep 1 '09 at 12:50
Ok, I was out of context there... The question isn't really about files being modified by multiple users, the scenario is rather one client process creating/updating files and a server process reading the same file. One solution I was offered was that the clients writes to a tmp file and then renames it when done (in context of FTP transfer). How would that work in the NFS case? Should I be worried in client cache etc...? – Kristian Sep 1 '09 at 13:17
I think it would work fine! – reinierpost Sep 14 '09 at 8:03

These conflicts are usually resolved through locks. It is upon application to ensure proper locking. That said, it needs to be noted that most of applications do tend to lock files, especially during writes.

share|improve this answer

NFS implements something called close-to-open consistency, which is a weak cache coherency model. See section 9.3.1 in the NFS 4 RFC.

In other words, when the client that has been modifying the file closes the file, the client will flush the written data to the server. If some other client opens the file after that, it will see the new content. Or if the other "client" is a local process on the server, it will see it immediately, no need to reopen.

If you need more fine-grained control over caching than that, you need to use byte-range locks. Again, see section 9.3.2 in the NFS 4 RFC. In that case, a NFS client will flush data when releasing a write lock, and revalidate its cache when acquiring a lock.

share|improve this answer

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.