(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 |
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 |
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 |
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 |
Free forum by Nabble | Edit this page |