[Samba] Win7 clients problem after upgrading samba file server to 4.12 on Arch

[pavlos]

sob., 9 maj 2020 o 14:37 Ralph Boehme <slow at samba.org> napisał(a):

> To be clear: if you're running into this issue that I'm seeing in the
> code, then this is *not* a client side bug. It's a server bug that only
> gets triggered by a specific access pattern. Likely Win 7 has a
> different pattern compared to other Windows versions which explains why
> you only see it there.
>
> -slow
>
>
Ralf,
Give me a while, I have to prepare the server moving it to the commit we
have our focus on.

Different patterns also observed between different file managers within the
same Windows session
I am historically using WIndows-only FreeCommander, recently switched to
multi-platform DoubleCommander. And I could observe different symptoms in
same use cases performed with three tools:

   - FreeCommander - it was usually "first detection tool" - could not
   expand folders of the share, not able to go into a subfolder, not showing
   files that should be visible
   - Windows Explorer - this tool could display a folder content, go into a
   subfolder, but any attempt to skip back two folders up in the address bar
   always was producing this funny message "*The process cannot access the
   file because it is being used by another process.*"
   - DoubleCommander - this was usually the most resistant file manager,
   still working after FC and WE refusing to work, of course also finally
   showing "unknown errors"

Use case scenarios were never the same: sometimes the server was refusing
any operation from the moment of connecting to the share, sometimes
misbehavior was observed after some time of normal functioning.
Wery strange, very unpredictable, not always easy reproducible...
As I have two Win7 boxes, I was always connecting one of them anonymously
in read-only mode, and the second using 'ala' read-write account.
In order to speed up my testing I was using cmd.exe command line to connect
and disconnect:
To connect:

   - R/W: net use y: \\192.168.1.116\nas /user:192.168.1.116\ala <password>
   /persistent:yes
   - R/O: net use y: \\192.168.1.116\nas /persistent:yes

I was not storing 'ala' password in Credential Manager.
To Disconnect after testing:

   - net use y: /delete

I am writing about that - maybe it is important.

Thanks! Pawel.