samba - May 2020 - 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.

Am 5/9/20 um 3:11 PM schrieb pavlos:
> sob., 9 maj 2020 o 14:37?Ralph Boehme <slow at samba.org
> <mailto: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.
I guess we can avoid that, the issue should be present in any version
after that commit.
>   * 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./"
this sounds like a reliable and simple reproducer, so please use this
access pattern when trying to reproduce the issue.

Fwiw, I've written a testcase that excercises the supposed problematic
access pattern and can reproduce a server bug in the commit you've bisected.

I have a WIP fix for master, can you give it a whirl?

CI: https://gitlab.com/samba-team/devel/samba/pipelines/144360879

Thanks!
-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/23a57c83/signature.sig>

Am 5/9/20 um 3:32 PM schrieb Ralph Boehme via samba:
> I have a WIP fix for master, can you give it a whirl?
here it is.

-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: tmp.patch
Type: text/x-patch
Size: 1803 bytes
Desc: not available
URL:
<http://lists.samba.org/pipermail/samba/attachments/20200509/9ec88802/tmp.bin>
-------------- 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/9ec88802/signature.sig>

sob., 9 maj 2020 o 15:35 Ralph Boehme <slow at samba.org> napisa?(a):
> Am 5/9/20 um 3:32 PM schrieb Ralph Boehme via samba:
> > I have a WIP fix for master, can you give it a whirl?
>
> here it is.
>
> -slow
>
>
Ralph, good news!

Applying the patch into the original source code of the 'open.c' file
removes the observed misbehavior.
So yes, you've touched and addressed the root-cause of the problem
on my side. MANY THANKS!
Double checked that from two WIn7 stations - x86 and x64, also from my Arch
LInux working computer.

Anyone else observing this thread and interested in the solution - PLEASE
use the patch from Ralph, TEST IT and REPORT IT.

I think that's all from my side. Now simply waiting to make it
officially public in the v4-12-stable branch, so it appears as a regular
update in Arch repository of packages. maybe in 4.12.3 maintenance release?

---

Thanks to All the Samba Community for the fantastic product! Great product,
Great Team!
I am happy I could get in touch with you.

Regards,
Pawel (aka pavlos).

On Sat, 2020-05-09 at 18:33 +0200, pavlos via samba
wrote:
> 
> Ralph, good news!
> 
> Applying the patch into the original source code of the 'open.c'
file
> removes the observed misbehavior.
> So yes, you've touched and addressed the root-cause of the problem
> on my side. MANY THANKS!
> Double checked that from two WIn7 stations - x86 and x64, also from my Arch
> LInux working computer.
> ---
> 
> Thanks to All the Samba Community for the fantastic product! Great product,
> Great Team!
> I am happy I could get in touch with you.
Awesome!  Thanks Pawel and Ralph!

Andrew Bartlett
-- 
Andrew Bartlett                       http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba

On Sat, May 09, 2020 at 03:32:05PM +0200, Ralph Boehme via samba
wrote:
> Am 5/9/20 um 3:11 PM schrieb pavlos:
> > sob., 9 maj 2020 o 14:37?Ralph Boehme <slow at samba.org
> > <mailto: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.
> 
> I guess we can avoid that, the issue should be present in any version
> after that commit.
> 
> >   * 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./"
> 
> this sounds like a reliable and simple reproducer, so please use this
> access pattern when trying to reproduce the issue.
> 
> Fwiw, I've written a testcase that excercises the supposed problematic
> access pattern and can reproduce a server bug in the commit you've
bisected.
> 
> I have a WIP fix for master, can you give it a whirl?
> 
> CI: https://gitlab.com/samba-team/devel/samba/pipelines/144360879
Actually, now I've looked at the test case reproducer I don't
feel at all bad that Volker didn't spot it in the original code,
or that I didn't spot it in my review :-).

That's such a pathalogical case that without the reproducer
showing how it happens I don't think we'd *ever* have spotted
this regression :-).

That's why user help is *so* important ! Thanks so much for
helping track down this regression.