[Samba] oplocks, kernel oplocks, kernel share modes, .. - how it all works?

Michael Tokarev mjt at tls.msk.ru
Tue Jan 24 21:00:09 UTC 2023

24.01.2023 23:23, Jeremy Allison пишет:
> On Tue, Jan 24, 2023 at 08:29:17PM +0300, Michael Tokarev via samba wrote:
>> 24.01.2023 20:22, Ralph Boehme via samba wrote:
>>> What Samba version is this? This:
>>>> LEASE()
>>> ... looks broken: the handle oplock/lease state claims to be a lease, which means the client didn't request an oplock but a lease which should not 
>>> have happened in the first place, because the global leases capabiltiy is not signaled by the server when kernel oplocks are enabled.
>>> I assume this is 4.17? That saw substantial changes in the core open handling, I'm worried that some of the subtle oplock/lease handling was broken 
>>> by those changes.
>> Yes this is 4.17[.4], the current stable (debian build of it).
>> I assumed LEASE() is okay because it is in fact SMB1 oplock, not a lease,
>> again as per your prior explanations.  As I wrote before, this LEASE()
>> appeared here (instead of LEASE(RH) etc) when I enabled kernel oplocks
>> (for this share anyway).
> What are the settings in your smb.conf ?

Here it is (with other share definitions omitted):

# Global parameters
	netbios name = PANDA
	netbios aliases = FS
	log level = 1
	prefork children = 2
	realm = TLS.MSK.RU
	security = ADS
	server role = member server
	winbind use default domain = Yes
	workgroup = TLS
	idmap config * : range = 5000-5099
	idmap config * : backend = tdb
	idmap config tls : unix_primary_group = yes
	idmap config tls : schema_mode = rfc2307
	idmap config tls : range = 1000-4999
	idmap config tls : backend = ad
	idmap_ldb:use rfc2307 = yes

	acl allow execute always = true

	comment = Workspace Area
	path = /ws/ws
	create mask = 0775
	writable = yes
	kernel oplocks = yes

> which means you end up with LEASE_OPLOCK, granted=SMB2_LEASE_NONE
> which is what you see with smbstatus.
> If you turn on kernel oplocks = yes, I think you must also
> set smb2 leases = no in order for this to work.

I've set smb2 leases = no (to global). I don't see these LEASE() anymore,
I see "NONE", "BATCH" and "LEVEL_II" now, like in old good times :)

Here's an example now (with the above config and 'smb2 leases=no' added):

78866  1006 DENY_WRITE 0x120089  RDONLY  BATCH /ws/ws   one   Tue Jan 24 23:48:23 2023
78866  1006 DENY_NONE  0x120089  RDONLY  NONE  /ws/ws   two   Tue Jan 24 23:48:23 2023

When I try to write to file "two", smbd does not care.  When however I try
to write to file "one", it seems to be reacting, getting SIGRT_3 signal,
doing some exchanges with the client, and changing this BATCH oplock into
NONE (so it works at least somehow). This ends up with F_SETLEASE, F_UNLCK
call.  DENY_WRITE is still there for the file "one".

I'm not sure it is what it should do here.  I'm trying to understand what
windows does with all this, if it will do the right thing when the file
actually changes on the linux side..



More information about the samba mailing list