pavlos
2020-May-09 12:21 UTC
[Samba] Win7 clients problem after upgrading samba file server to 4.12 on Arch
sob., 9 maj 2020 o 10:34 Ralph Boehme <slow at samba.org> napisa?(a):> Hi Pawel, > Can you share a network trace and loglevel 10 debug log of a reproducer? > The links you posted earlier don't seem to work anymore. > > -slow >...because I have treated them as not important and have deleted them, after I had found the proper commit in code. If this is important - I may reproduce them, this time tracing more precisely moments of misbehavior. Pawel.
Ralph Boehme
2020-May-09 12:37 UTC
[Samba] Win7 clients problem after upgrading samba file server to 4.12 on Arch
Am 5/9/20 um 2:21 PM schrieb pavlos:> sob., 9 maj 2020 o 10:34?Ralph Boehme <slow at samba.org > <mailto:slow at samba.org>> napisa?(a): > > Hi Pawel, > Can you share a network trace and loglevel 10 debug log of a reproducer? > The links you posted earlier don't seem to work anymore. > > -slow > > ...because I have treated them as not important and have deleted them, > after I had found the proper commit in code. > If this is important - I may reproduce them, this time tracing more > precisely moments of misbehavior.yes, this would be helpful. Otherwise I may end up fixing a bug which is different then yours. :) 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 -- Ralph Boehme, Samba Team https://samba.org/ Samba Developer, SerNet GmbH https://sernet.de/en/samba/ GPG-Fingerprint FAE2C6088A24252051C559E4AA1E9B7126399E46 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: <http://lists.samba.org/pipermail/samba/attachments/20200509/6aa11add/signature.sig>
pavlos
2020-May-09 13:11 UTC
[Samba] Win7 clients problem after upgrading samba file server to 4.12 on Arch
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.
Seemingly Similar Threads
- Win7 clients problem after upgrading samba file server to 4.12 on Arch
- Win7 clients problem after upgrading samba file server to 4.12 on Arch
- Win7 clients problem after upgrading samba file server to 4.12 on Arch
- Fwd: Win7 clients problem after upgrading samba file server to 4.12 on Arch
- Win7 clients problem after upgrading samba file server to 4.12 on Arch