samba-4.5.10 member server: issues around locks

[Samba - General mailing list]

(new thread, same environment)

Clients get thrown out of their software from time to time because of
issues with some ISAM db files (afai understand).

They access customer-related files and some DAT-file gets locked by the
software.

I tried to exclude that specific filename from locking:

veto oplock files = /BL6F.DAT/

Unfortunately that wasn't enough.

I now set for that share:

level2 oplocks = No
oplocks = No

and wait for feedback if that happens again.

* I assume the client has to reconnect, "killall -HUP" seems not to
change that behavior for existing connections?

* Is there a recommended best practice to find the correct level of
locking for a share? What to disable first ... etc ?

* I run loglevel 3 and increased log file size to maybe catch such a
dropped connection issue.

--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba

[Samba - General mailing list]

Am 2017-07-13 um 11:06 schrieb Stefan G. Weichinger via samba:

> * Is there a recommended best practice to find the correct level of
> locking for a share? What to disable first ... etc ?
>
> * I run loglevel 3 and increased log file size to maybe catch such a
> dropped connection issue.

Could the change from NT1 to SMB3 be related?

I test

server max protocol = SMB2

--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba

[Samba - General mailing list]

Am 2017-07-14 um 09:52 schrieb Stefan G. Weichinger via samba:

> Am 2017-07-13 um 11:06 schrieb Stefan G. Weichinger via samba:
>
>> * Is there a recommended best practice to find the correct level of
>> locking for a share? What to disable first ... etc ?
>>
>> * I run loglevel 3 and increased log file size to maybe catch such a
>> dropped connection issue.
>
> Could the change from NT1 to SMB3 be related?
>
> I test
>
> server max protocol = SMB2

Rolled that back as it seems to me that clients would have to reconnect
or reboot to accept that new max protocol.

Still searching for a fix here and found this in release notes for
samba-4.7 RC:

> The "strict sync" global parameter has been changed from
> a default of "no" to "yes". This means smbd will by default
> obey client requests to synchronize unwritten data in operating
> system buffers safely onto disk. This is a safer default setting
> for modern SMB1/2/3 clients.

right now I have "strict sync = No", would I benefit from toggling that
one maybe? Samba-4.5.10 in my case, though.

--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba

[Samba - General mailing list]

Am 2017-07-14 um 11:07 schrieb Stefan G. Weichinger via samba:

> Still searching for a fix here and found this in release notes for
> samba-4.7 RC:
>
>> The "strict sync" global parameter has been changed from
>> a default of "no" to "yes". This means smbd will by default
>> obey client requests to synchronize unwritten data in operating
>> system buffers safely onto disk. This is a safer default setting
>> for modern SMB1/2/3 clients.
>
> right now I have "strict sync = No", would I benefit from toggling that
> one maybe? Samba-4.5.10 in my case, though.

Toggling that made the share non-reacting for me.

But I removed an old "force group" clause and chowned the files to
"domain users" now. I had googled some warning to not use "force user"
with oplocks ... so maybe this will help in my case as well.

Users test right now ;-)

--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba