NFS4: howto lock a file during write?

suskewiet · July 2, 2011, 1:41pm

I have setup a NFS4 server and client on opensuse 11.4 KDE.

When I open a textfile on the client I can edit the file. Before saving this file, I open the file on the server as well. Strangely, I don’t get an error that the file is locked. It just notices that the file needs to be repared. But I can edit and save the file on the server. If I then close the file on the client (without saving) and reopen the file on the client, the changes saved on the server are visible.

This means that there seems to be no file locking whatsoever. How can I enable file locking so that a popup will show on the server that the file is already open on another pc, and I can only open the file readonly?

This is my /etc/exports on the server:

/nfs4exports    10.0.2.0/24(fsid=0,ro,insecure,all_squash,sync,no_subtree_check,anonuid=1000,anongid=100) 192.168.1.0/24(fsid=0,ro,insecure,all_squash,sync,no_subtree_check,anonuid=1000,anongid=100)
/nfs4exports/data       10.0.2.0/24(rw,nohide,insecure,all_squash,sync,no_subtree_check,anonuid=1000,anongid=100) 10.0.2.0/24(rw,nohide,insecure,all_squash,sync,no_subtree_check,anonuid=1000,anongid=100)

This is my entry in /etc/fstab on the client:

10.0.2.0/24:/data       /media/data     nfs4    defaults,user 0 0

nrickert · July 2, 2011, 3:12pm

A few points.

(1) It has always worked as you describe.
(2) It probably depends on which editor you use.
(3) There is file locking over NFS, but your editor might not be using it.
(4) File locking over NFS has always been unreliable.

I have mostly used “vi” (currently, that’s “vim”). Traditional “vi” behavior is to make a temporary copy of the file, and edit that. Then, when saving changes, copy back to the original. The effect is that the original file is not kept open, and if it is ever locked by “vi”, then it is only locked for the brief time that it is open for reading or for saving.

suskewiet · July 2, 2011, 3:37pm

I’m using kwrite. I would assume that the locking is done unregardless of the editor that is used. I can hardly believe that locking would not be supported by NFS4 since files edited by multiple clients at the same time is garanteed to give problems.

nrickert · July 2, 2011, 6:51pm

As far as I know, “kwrite” saves the edited data as a new file, after renaming the old file as “filename.old”. Locking is not needed if you do it that way.

Windows seems to use mandatory file locking. Unix more commonly uses advisory file locking.

Yes, file locking is supported by NFS4. But that doesn’t guarantee that it is reliable.

suskewiet · July 2, 2011, 8:50pm

No kwrite doesn’t create a backup file, and that’s not want I would like as well, because then there would be needless backups scattered over my hard drive.

Right now: locking is not unreliable, it is just not present at all. Every user in my network can edit and save at will. This means that the last person who saves the file eventually determines the content…

I can’t believe nfs has no decent locking feature, since that would make it useless

martin_helm · July 2, 2011, 9:29pm

suskewiet wrote:

> I can’t believe nfs has no decent locking feature, since that would
> make it useless
>
Following http://www.ietf.org/rfc/rfc3530.txt it has the locking feature you
are after. Since I can see at the very beginning of the document

Unlike earlier versions, the NFS version 4
protocol supports traditional file access while integrating support
for file locking and the mount protocol.

you may have to tell it somehow that it should not use only the traditional
file access but respect locking. I never used it so I cannot help further.

suskewiet · July 3, 2011, 11:15am

I also found on the web that locking should be integrated in NFSv4, whereas for NFSv3 you had to use lockd to lock files. But I don’t find anything on the web how to enable file locking for NFSv4. Or maybe my setup is incorrect causing the lock to be turned off? But how can I check this?

robin_listas · July 4, 2011, 12:50am

On 2011-07-02 19:06, nrickert wrote:
>
> As far as I know, “kwrite” saves the edited data as a new file, after
> renaming the old file as “filename.old”. Locking is not needed if you
> do it that way.

Of course it is needed! Another user might be doing the same at the same time.

> Windows seems to use mandatory file locking. Unix more commonly uses
> advisory file locking.

Windows has an API for locking files on open, since MsDos times. Linux
doesn’t have a unique method.

> Yes, file locking is supported by NFS4. But that doesn’t guarantee
> that it is reliable.

No common API. Not mandatory to use the mandatory system on every open file
operation.

–
Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

djh-novell · July 4, 2011, 11:47am

suskewiet wrote:
> I can’t believe nfs has no decent locking feature, since that would
> make it useless

You obviously haven’t been using NFS for long. It’s been around for a
very long time and is immensely useful. But it has its quirks and you
need to be aware of them or else you will be bitten. There’s lots of
good material to read and it would be wise to do so.

The answer to your question about NFS file locking is that people
generally find a way to avoid the need for it. For example, if you’re
developing a shared code base, you make a local copy and merge changes
back with a version control system. If you edit a file with vim and then
try to edit the same file from somewhere else, vim warns you and offers
various options, so you can’t accidentally damage the file. If you have
shared data, use a database etc etc.

Ecky · July 4, 2011, 4:01pm

Wouldn’t the last person who saves the file determine the content even when locking is functioning?

If I edited a file and then you applied further edits when it became unlocked the state of the file would be as it was when you saved it, my edits could have been deleted, so it seems to me that aspect would be true with or without unlocking

Is every user being able to edit files at will actually the behaviour you want I have to wonder, if the files you’re talking about are meant to be shared then djh-novell makes some valid points

Incidentally the reason this thread caught my eye is that I’ve had to implement a script to run at login and delete kmail’s lock file as it doesn’t get deleted/cleared in the nfs /home/user dir when the user logs out, resulting in an error about kmail being running on another machine when one logs in from somewhere else and tries to check mail

So in my case at least, locking isn’t ideal and without it’s own problems either

robin_listas · July 5, 2011, 4:05am

On 2011-07-04 16:06, Ecky wrote:
>
> suskewiet;2360598 Wrote:
>>
>> Every user in my network can edit and save at will. This means that the
>> last person who saves the file eventually determines the content…
>>
>
> Wouldn’t the last person who saves the file determine the content even
> when locking is functioning?

No, because a second person is not allowed to edit the file till the first
one releases the file. The second person might not even be allowed to read
the file, with a full lock in force.

> Incidentally the reason this thread caught my eye is that I’ve had to
> implement a script to run at login and delete kmail’s lock file as it

IMO, lock files are a hack, for not using proper kernel locks.

–
Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

glistwan · July 5, 2011, 10:32am

Yes it does work this way the backup file name starts with ~ or ends with it (don’t remember exactly). Test this on non NFS mount and see for yourself.

Best regards,
Greg

robin_listas · July 5, 2011, 11:20am

On 2011-07-04 11:47, Dave Howorth wrote:

> The answer to your question about NFS file locking is that people
> generally find a way to avoid the need for it. For example, if you’re
> developing a shared code base, you make a local copy and merge changes
> back with a version control system. If you edit a file with vim and then
> try to edit the same file from somewhere else, vim warns you and offers
> various options, so you can’t accidentally damage the file. If you have
> shared data, use a database etc etc.

Plain old MsDos had functions to lock a region of a file for editing, not
only the whole file. Mandatory locks. When I first came to linux in 1998 I
missed that.

–
Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

martin_helm · July 5, 2011, 12:08pm

Carlos E. R. wrote:
> Plain old MsDos had functions to lock a region of a file for editing, not
> only the whole file. Mandatory locks. When I first came to linux in 1998 I
> missed that.
>
The lockf function does that (I do not know if it was available or worked
that way back in 1998) but there seems to be no equivalent command for this
function, just for flock there is also a command which locks the whole file.

robin_listas · July 5, 2011, 3:52pm

On 2011-07-05 12:08, martin_helm wrote:
> Carlos E. R. wrote:
>> Plain old MsDos had functions to lock a region of a file for editing, not
>> only the whole file. Mandatory locks. When I first came to linux in 1998 I
>> missed that.
>>
> The lockf function does that (I do not know if it was available or worked
> that way back in 1998) but there seems to be no equivalent command for this
> function, just for flock there is also a command which locks the whole file.

Having those functions, it looks weird to me that programs still lock files
by creating fnames.lock files instead. Or that they do neither across NFS.

–
Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

suskewiet · July 8, 2011, 7:59pm

I also think this is a big flaw of NFS. It is much more user friendly if people can’t, by mistake, edit the same file at the same time, leaving the result of the final person who saved it. You can’t expect people to know which file is being edited by who at all times. The locking should help preventing these weird scenario’s. Espacially at home with family members sharing the same files, thus not editing source files which are restricted by a source control system like subversion.

Well, it seems windows has actually done something better than linux…

nrickert · July 8, 2011, 9:03pm

In my opinion, the problem is with your expectations.

Recently, I edited a file with “kwrite”. While still editing, I looked at that file from a terminal window (an xterm). Using “fuser”, I could see that no process had the file open. So “kwrite” is briefly opening the file to read the content, then closing it. My “kwrite” application keeps editing, using either a temporary file copy or a memory copy. And then, when I save, “kwrite” briefly opens the file to write back the updated data.

This was a file on the local hard drive, so NFS is not even involved. If the system were using mandatory file locking, that would not change anything. If the file is not open in any process, then it won’t be locked.

I’m not sure whether there is a version of “kwrite” for Windows. But if there is, then it probably works the same way and the Windows mandatory file locking would not be involved except for the very brief time (probably less than a second) that “kwrite” actually has the file open.

Then use locking judiciously, but only in weird scenarios.

Example: Use “vipw” for editing “/etc/passwd” - that has locking built in.

That should be mostly a matter of always using a version control system for files that are updated by multiple people.

martin_helm · July 8, 2011, 9:11pm

nrickert wrote:
> That should be mostly a matter of always using a version control system
> for files that are updated by multiple people.
>
Or if it is about documents and one uses openoffice or libreoffice they will
take care to lock the files while editing, no need for a version control
system in that case.