samba - Jan 2023 - oplocks, kernel oplocks, kernel share modes, .. - how it all works?

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
[global]
	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

[ws]
	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..

Thanks!

/mjt

On Wed, Jan 25, 2023 at 12:00:09AM +0300, Michael Tokarev
wrote:
>24.01.2023 23:23, Jeremy Allison ?????:
>..
>>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 :)
Oh, very interesting. Something is wrong in our code then, as Ralph
already mentioned we have:

         capabilities = 0;
         if (lp_host_msdfs()) {
                 capabilities |= SMB2_CAP_DFS;
         }

         if (protocol >= PROTOCOL_SMB2_10 &&
             lp_smb2_leases() &&
             lp_oplocks(GLOBAL_SECTION_SNUM) &&
             !lp_kernel_oplocks(GLOBAL_SECTION_SNUM))
         {
                 capabilities |= SMB2_CAP_LEASING;
         }

so setting "kernel oplocks = yes" should prevent SMB2_CAP_LEASING
being returned to the client. A wireshark trace when you remove
the "smb2 leases = no" line would be good to look at.
>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".
Yes, that's the code working correctly. When you do a local open, smbd
is getting the signal and telling the client to downgrade to oplock=NONE.

The "DENY_XXXX" modes have *nothing* to do with the oplock or lease
state,
they are restrictions on open types - not leasing or oplocks.
>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..
Yes, it's doing the right thing.