Interesting file locking problem with Samba and Windows & Linux clients arose at work last week:
- 1st Linux machine with a CIFS-mounted Samba share has an OpenOffice.org document open on the share.
- 2nd Linux machine with the same CIFS-mounted share opens the OOo file. OOo has full write access to the file.
- Windows machine tries to open the OOo file. OOo gets read-only access. (the correct behaviour)
This is really a Linux OOo bug, but you can circumvent it by enforcing a particular file locking policy with Samba.
OOo’s file locking on Windows is handled nicely because the file locking interface it uses is, as far as I can tell, smart enough to work out whether the file is on a remote share, and if so it modifies the locking calls to be more CIFS-ish.
From various bug and forum posts, OOo on Linux isn’t afforded same luxury. It will make a “standard” locking call that doesn’t get translated to a more reliable and CIFS aware call. This standard locking call is used everywhere, and makes the OOo developer’s jobs easier because they don’t have to maintain CIFS aware code, further reinforcing one of my favourite graphics:
So, it becomes a process of finding the right smb.conf incantations. This is what I found worked:
[global]
...
kernel oplocks = no
[someshare]
path = /path/to/share
oplocks = yes
share modes = yes
locking = yes
strict locking = no
blocking locks = no
...
Replace ... with your normal share or global settings.
I’ve tested this successfully on Ubuntu Edgy and Dapper, though it’s been tried on a Sarge-like build and not worked correctly.
An interesting side effect that I haven’t confirmed: the OOo + CIFS + Linux combination works as intended, but OOo + Windows get a constant read-only status on the file. Looks like the enforced Samba locking behaviour doesn’t bode well with Windows.
Further testing on both fronts is required, but people running into this OOo problem in pure Linux environments should find it a handy fix.
