samba within nfs, locking mechanism fails
Christopher R. Hertel
crh at samba.org
Mon Feb 25 11:44:42 MST 2013
Vincenzo,
CTDB is only the solution if you have shared storage and a cluster file
system behind the two instances of Samba.
The configuration you have is a bit unusual. If you consider the number of
semantic conversions that need to take place from the client to the ServerB
to ServerA and back again, you can see why we would discourage this kind of
setup.
With respect to the locking... You need to have POSIX locking enabled if
there is going to be even a remote chance that this setup will appear to
work. Samba itself manages SMB byte-range locks. NFS has a locking daemon
that handles the kinds of byte-range locks you would need to use.
So... here's my best guess as to what happens when you lock a range from
clientB.
1) ClientB sends the lock request to ServerB.
2) ServerB (Samba) checks its internal table to see if the lock can be
granted. If not, it returns an error (END).
3) If the lock can be granted, Samba checks whether or not it can obtain
a POSIX byte-range lock from the underlying file system (NFS).
3a) The NFS lockd on ServerB has to ask the NFS lockd on ServerA
whether or not the lock can be granted.
3b) ServerA checks with the underlying local file system to see
whether or not the lock can be granted. Note that Samba
running on ServerA will set byte-range locks as needed also.
The byte-range locks on the local file system on ServerA are
the final arbiter of lock availability.
If the lock cannot be granted, an error is returned (END).
4) If the POSIX lock can be granted, then we go all the way back up the
chain from the local FS on ServerA through NFS to Samba on ServerB
(which sets the SMB lock) and then to ClientB. ClientB is notified
that it has a lock.
...and if that isn't complicated enough, keep in mind that Microsoft Office
products do some very, very odd things when opening files. I don't know
enough about that to share the details, but it is possible (based on my weak
understanding of this aspect) that the two nodes are both opening copies of
the spreadsheet, and not the same spreadsheet at all.
Dave:
In theory, theory and practice are the same. In practice, they're not.
Chris -)-----
On 02/25/2013 11:04 AM, David Collier-Brown wrote:
> NFS locks don't interoperate with SMB locks: everyone should access the
> files via the same protocol if you want locks to work. If I needed to
> interoperate with WinBlows, I used to use smbclient on the Unix side. I
> suspect you can use an smb mount these days (;-))
>
> --dave
>
> On 02/25/2013 10:04 AM, Vincenzo De Sanctis wrote:
>> this is the case:
>>
>> serverA [ CentOs 5.6 kernel 2.6.18-238.12.1.el5.centos.plus, Samba ver. 3.5.21 ]
>> serverB [ CentOS 5.6 kernel 2.6.18-348.1.1.el5.centos.plus, Samba ver.
>> 3.6.6-0.129.el5 ]
>> clientA [ WindowsXP ]
>> clientB [ WindowsXP ]
>>
>>
>> The serverA shares via Samba the resource [test]
>>
>>
>> [global]
>>
>> workgroup = DMIT
>> netbios name = SAMBA
>> server string = DMIT domain server
>> interfaces = eth0
>> smb ports = 445
>> encrypt passwords = yes
>> smb passwd file = /etc/samba/smbpasswd
>> passdb backend = smbpasswd
>> username map = /etc/samba/smbusers
>> log file = /var/log/samba/pc/%m.log
>> time server = Yes
>> logon script = logon.bat
>> logon path =
>> logon drive = M:
>> logon home = \\%L\%U
>> domain logons = yes
>> os level = 33
>> preferred master = yes
>> domain master = yes
>> local master = yes
>> printjob username = %M\%U
>> hide dot files = No[netlogon]
>> path = /etc/samba/netlogon
>> ; max protocol = smb2
>>
>>
>> [test]
>> comment = test
>> path = /test
>> read only = no
>> writable = yes
>> create mode = 0775
>> force create mode = 0775
>> directory mode = 02775
>> force directory mode = 02775
>> public = no
>> oplocks = no
>>
>>
>> il serverB monta tramite client nfs la risorsa /test (mount
>> serverA:/test /test)
>> Queta e' il semplicissimo file di configurazione smb.conf di serverB:
>>
>> [global]
>>
>> workgroup = DMIT
>> domain master = no
>> domain logons = no
>> encrypt passwords = yes
>> security = server
>> password server = serverA
>> interfaces = eth0
>> smb ports = 445
>>
>> [test]
>> comment = test
>> path = /test
>> read only = no
>> writable = yes
>> create mode = 0775
>> force create mode = 0775
>> directory mode = 02775
>> force directory mode = 02775
>> public = no
>> oplocks = no
>>
>>
>>
>> Now on the clientA I open an excel2003 file from \\serverA\test and on
>> clientB i open the same file but from \\serverB\test (consider that
>> test is the same directory mounter from serverA via nfs)
>>
>>
>> This is what happens:
>>
>> 1) I can open without problem the file on clientA from \\serverA\test,
>> instead I have problem to open the the same file from \\serverB\test
>> (after 5min later it goes in timeout)
>>
>>
>> 2) If I add "posix locking = no" on serverA and on serverB both
>> excel2003 files open without the locking mechanism.
>>
>> 3) I tried various combinations changing kernel oplocks, oplocks,
>> level2 oplocks, posix locking, locking, strict locking, nt acl support
>> but nothing changed.
>>
>>
>> 4) I tried to open the same file from the same serverA (from clientA
>> and from clientB) without nfs and now the locking works well (both
>> from \\serverA\test)
>>
>>
>> The strange thing is that on my company newtwork there are many old
>> samba servers (samba 2.3) and they works well within nfs.
>> The proper way to use samba like a cluser is DFS insead of NFS, but
>> now I can not consider a migration or an upgrade to all the newtork,
>> so the best way at the moment is to use nfs, like the prevoiis
>> sysadmin did.
>>
>>
>> Have you had experience about this strange case?
>> Are there known bugs regarding the new samba versions + nfs ?
>>
>
>
--
"Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X
Samba Team -- http://www.samba.org/ -)----- Christopher R. Hertel
jCIFS Team -- http://jcifs.samba.org/ -)----- ubiqx development, uninq.
ubiqx Team -- http://www.ubiqx.org/ -)----- crh at ubiqx.mn.org
OnLineBook -- http://ubiqx.org/cifs/ -)----- crh at ubiqx.org
More information about the samba-technical
mailing list