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

On 24/01/2023 21:47, Jeremy Allison wrote:
> On Tue, Jan 24, 2023 at 09:44:48PM +0000, Rowland Penny via samba wrote:
>> On 24/01/2023 21:36, Jeremy Allison wrote:
>>>
>>> Ah, that code has gone through so many engineers and changes,
>>> who knows who originally added the bug :-) :-) :-).
>>>
>>> Probably me though :-).
>>
>> See: 
>>
https://git.samba.org/?p=samba.git;a=commitdiff;h=556bf2ee006d14eb206c701bd8d375efb940140b
> 
> Damn you Rowland, you are right again :-).

So, are we back to what I said originally ? that it is a BAD idea to 
locally modify anything in a Samba share and it should only be modified 
by Samba or from a SMB client ?

Rowland

On Tue, Jan 24, 2023 at 09:51:01PM +0000, Rowland Penny via samba
wrote:
>
>So, are we back to what I said originally ? that it is a BAD idea to 
>locally modify anything in a Samba share and it should only be 
>modified by Samba or from a SMB client ?
It is... inadvisable to do local modifications. Having said that
the "kernel oplocks" parameter (when set in the [global] section only)
on Linux will allow this to be done safely w.r.t. file-level caching
at the cost of falling back to the old oplock model rather than the
modern SMB2 leases.

It will depend on applications being used that understand each
others locking and simultaneous open semantics in order to be
safe though.

So yeah. Advanced option, only use if you *really* know what
you're doing and understand the risks involved.

I think Michael is asking the right questions to get to something
that will work for him. And after all, the purpose of this
list is to help people to use Samba to do really dangerous
things :-) :-) :-).

25.01.2023 00:51, Rowland Penny via samba ?????:
> So, are we back to what I said originally ? that it is a BAD idea to
locally modify anything in a Samba share and it should only be modified by Samba
> or from a SMB client ?
That doesn't work either. In our example, we release an application
(usually every evening) and some workstations might have the files
open still. If we'll do this using samba, it wont work because samba
will not let us to modify the open (and locked) files, it will just
fail for everyone if at least one client has it open.  People tend
to forget to close it and all sorts of other things.

In our case, the app and whole share is read-only.

And once again, this is about sharing files between unix and windows.
We either do that or we require samba private filesystem which can
not be touched by anything but samba.

/mjt