[linux-cifs-client] linux cifs file locking samba server

[Bernard Gray]

Hi All,
Some background:
I've been working on and off for several years to try and resolve a long
standing issue with File Locking between Linux Clients on a Samba Server.
In short, when two linux clients mounted a share using smbfs, then opened
the same document (in OpenOffice) on a samba server, both were given rw
access, therefore the last client to save overwrites any other changes by
any other client.

Bug submitted to OOo: http://www.openoffice.org/issues/show_bug.cgi?id=57712


The first change suggested was to mount as cifs instead of smbfs. This
produced unpredictable results, but research and recommendations suggested
we stick with it.
Approximately 12 months ago, we finally got a major breakthrough after
contacting Andrew Bartlett @ Samba directly:
"From my research it would appear that the current 2.6.17-rc5
has the client support the the locking you need, and Samba 3.0.23rc1 has
the server half."
Tested using the versions suggested with Openoffice 2.0, and it worked!
...sort of. This time we didn't lose any data, however the error reporting
by OpenOffice is still very poor (I know this probably isn't the cifs
project responsibility, however I'm hoping you can help me construct a good
bug report for the ooo team). There were also a few unpredictable results
with the way oplocks were managed on the server -

Specific setup:
Clients: Debian Sid, 2.6.18 kernel, Openoffice 2.0.4
Server: Red Hat Enterprise Linux ES release 4, 2.6.9-22.0.2.ELsmp kernel,
samba 3.0.23c-4

Scenario 1:
When two clients open a file but don't save changes, the second client gets
OpenOffice reporting that the file needs to be repaired, then fails in the
repair process.
smbstatus with client 1 only accessing the file:
11143        1158       DENY_NONE  0x12019f    RDWR       EXCLUSIVE
/samba/it   Bernard/OpenOffice/test.ods   Fri Nov 24 08:49:58 2006

smbstatus when client 2 tries to access the file - note the oplocks changed
from EXCLUSIVE to NONE for client 1
11143        1158       DENY_NONE  0x12019f    RDWR       NONE
/samba/it   Bernard/OpenOffice/test.ods   Fri Nov 24 08:49:58 2006
11116        1003       DENY_NONE  0x120089    RDONLY     NONE
/samba/it   Bernard/OpenOffice/test.ods   Fri Nov 24 08:50:30 2006


Scenario 2:
A client opens a document, makes a change and saves, OpenOffice throws an
error "Could not create backup copy" and doesn't save. Clicking save again
saves the document.
Examining the smbstatus output on the server, before clicking save:
11116        1003       DENY_NONE  0x12019f    RDWR       EXCLUSIVE
/samba/it   Bernard/test2.odt   Thu Nov 23 16:28:48 2006

smbstatus after receiving the "Could Not create backup copy" error - note
the oplock has changed from EXCLUSIVE to NONE :
11116        1003       DENY_NONE  0x12019f    RDWR       NONE
/samba/it   Bernard/test2.odt   Thu Nov 23 16:28:48 2006

smbstatus after clicking [OK] on error and clicking save again - Note the
oplock changed back to EXCLUSIVE:
11116        1003       DENY_NONE  0x12019f    RDWR       EXCLUSIVE
/samba/it   Bernard/test2.odt   Thu Nov 23 16:32:14 2006


Scenario 3:
As in Scenario 2, except a second client tries to open the file after the
first client has received the "Could not create backup copy" error (ie
oplock set to NONE for client 1)
The second client is presented with a filter selection dialog by openoffice
- choosing the correct filter throws an error "test2.odt is corrupt and
therefore cannot be opened. Should OpenOffice repair the file?". The repair
then fails

Examining smbstatus while the filter dialog is open:
11116        1003       DENY_NONE  0x12019f    RDWR       NONE
/samba/it   Bernard/test2.odt   Thu Nov 23 16:32:14 2006
11143        1158       DENY_NONE  0x120089    RDONLY     NONE
/samba/it   Bernard/test2.odt   Thu Nov 23 16:34:42 2006

After the first client clicks [OK] on the "Could not create backup copy"
dialog, the second client OKs all error messages - smbstatus output:
<none>

Now the second client can reopen the file and edit/save it, and effectively
steal the rw lock from the first client.

smbstatus after the second client steals the lock from client 1:
11156        1182       DENY_NONE  0x120095    RDWR       EXCLUSIVE
/samba/it   Bernard/test2.odt   Thu Nov 23 16:35:47 2006

When the first client now tries to save, "Could not create backup copy"
dialog appears, click OK, the save icon greys out and stays greyed out
despite making further changes. If client 1 tries to save, the document then
changes it's mode to (read only). This implies that getting a document to
open (read only) is possible, and OpenOffice can behave correctly - it's
just that it's not doing it right from the start.

As you can see, there are some fairly unpredictable results here. I see this
as a serious useability bug, but it's quite difficult to explain, and even
more difficult for me to pinpoint where the error is occurring.


Ideally, I'd like to see the following occur:
The first client opens the document and is given the rw lock, the second and
subsequent clients open the document and are granted a ro lock for viewing
only. It would even be nice if the client could query the server for which
user holds the rw lock and return that to the clients with ro locks.
The rw lock should be released if the first client closes the document, or
changes the mode in OpenOffice to read-only.


I'm not sure whether there's the possibility of data loss - you could
certainly see in scenario 3 that after client 1 loses it's rw lock then
continues editing that they will be forced to manually merge their changes
with client 2's changes, but I'm not sure if I can create a scenario where
data will actually be overwritten. Note that I have tested this with koffice
(kwrite specifically), and the original issue of clients overwriting each
others changes appears.

At this stage it is holding up further rollouts of Linux to the desktops
(stalled at ~35% of the desktop fleet).

I work for an Australian company (I believe a few of the core samba team
members are also Australian), and we will certainly consider contracting
samba developers to fast track an investigation and resolution if this is a
possibility.

If anyone has any suggestions/fixes/info/links/requests for more info/etc I
will happily provide.

My apologies for the long post, if there's a better place for this, please
let me know.

Thanks,

Bernard Gray
-------------- next part --------------
HTML attachment scrubbed and removed