[Samba] CIFS + NFS'ing a single filesystem w/ locking
Adam D. Morley
adam-samba at gmi.com
Sat Jan 7 02:24:22 GMT 2006
I have a Solaris 10 server exporting UFS directories using built-in NFS.
I've built Samba 3.0.20b from OpenPKG (www.openpkg.org). I have a
Solaris 10 (x86) client mounting the NFS share and opening OpenDocument
files using StarOffice 8 (SO8, aka OO2.0). I also have a Windows 2003
Terminal Server mounting the Samba share and opening documents with SO8.
This is a temporary development environment, so I can screw around with
it. I have a similar, production environment using RHEL3 (clients) and
Solaris 9 (server), with no Samba. Ie: I would like to export NFS
shares as CIFS shares using Samba. But: I want file locking.
StarOffice 8/OO2.0 support file locking, whereby the first user to open
a file will place a lock* on the file, and the other users will get a
read-only file. This works fine with NFS & nlockmgr (cross platform,
linux/solaris). However, when I add Samba to the mix, it doesn't seem
to see the locks. I am under the impression this is because Solaris
does not support kernel oplocks. Here is my smb.conf:
workgroup = test
security = share
path = /export/home/shared
read only = No
guest ok = yes
locking = yes [I've tried leaving this out]
kernel oplocks = yes [I've tried this as yes and left it out]
oplocks = yes [I've tried not setting this, and diff combinations with locking]
level2 oplocks = no [I've tried not setting this]
I also attempted to NFS mount the share from a RHEL3 box (which should
support kernel oplocks) and then share it back out with Samba. Locks do
not work here either (yes, I had anon and root properally set). I would
think that the kernel oplock code in RHEL3's kernel would allow the locks
to propegate down from Samba, and back out to the NFS server using lockd.
It could also be that my understanding of what a "lock" is is not
exactly correct. Ie: NFS lock != Samba lock. I have some indication of
this based on the locking directory that exists for Samba, and the fact
that lock on Windows is not implemented the same way as on UNIX.
The specific symptoms of the lock not working are the following:
- a file first opened on the solaris client will yield a "file type"
selection box on the windows box (a sign that windows can't read the file,
and a sign it is seeing some kind of lock)
- a file first opened on the windows side, and then opened on the
solaris client side will show read/write status on both clients
- if the windows client then tries to save, it will get an I/O
error (so it must be seeing some kind of lock...)
- if the solaris client tries to save, it can save fine, not
being informed that another user has the file open
This is obviously somewhat problmatic! Am I totally missing something
here, or does NFS/CIFS file locking simply not work? I seem to remember
reading somewhere that NFS/CIFS from a Linux host works fine, and that
NFS/CIFS on other systems won't work (save IRIX) because they don't have
kernel oplock support for Samba.
So: have I done something wrong, or is this "the way things are?"
OR: Is it that the type of lock placed on the file when *nix OO2.0 opens
a file is incompatible with the type of lock Samba thinks is "ok" wrt
oplocks in the Samba code?
*: It looks like lock type is a F_WRLCK on *nix, and a "dwAccess |=
GENERIC_WRITE" for win32, based on my cursory, vastly under-knowledged
reading of the OpenOffice 2.0 source code (sal/osl/unx/file.cxx and
sal/osl/w32/file.cxx). Line 2450 in w32/file.cxx, line 548 in
Thanks a bunch!
More information about the samba