https://bugzilla.suse.com/show_bug.cgi?id=1194945 Takashi Iwai changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ematsumiya@suse.com, | |palcantara@suse.com, | |tiwai@suse.com -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1194945 https://bugzilla.suse.com/show_bug.cgi?id=1194945#c1 Enzo Matsumiya changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mantel@pre-sense.de Flags| |needinfo?(mantel@pre-sense. | |de) --- Comment #1 from Enzo Matsumiya --- Hi, thanks for the detailed report. Unfortunately I couldn't reproduce the issue with neither .72 release nor with the latest .106. Could you try using the latest as well just so we're on the same page please? Also please provide the packet capturing with the umount time frame, e.g.: # <mount share> # tcpdump -s 0 -w /tmp/trace.pcap & pid=$! # sleep 3 # umount /mnt # sleep 3 # kill $pid Another observation: IIUC, this is failing from an application "app" you're using, right? i.e. mount and umount (among other commands) are being issued by the application. Is it possible you can try a simple manual test? Only mount and umount right after is enough for now. My understanding so far: cifs will try to access some path components sometimes, in this case via cifs_statfs() function, and it it's possible it's getting STATUS_ACCESS_DENIED from the server for the \company_users\ link/dir, but your app is translating that error to errno 32 (broken pipe) and bailing immediatelly as a fatal error (which it's not always the case for cifs). This is all guesswork, but further testing will confirm what debugging path should we follow here. -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1194945 https://bugzilla.suse.com/show_bug.cgi?id=1194945#c3 --- Comment #3 from Enzo Matsumiya --- (In reply to Enzo Matsumiya from comment #2)

Hi @Ales, any updates here?

Alex, rather. -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1194945 James McDonough changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |samba-maintainers@SuSE.de -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1194945 https://bugzilla.suse.com/show_bug.cgi?id=1194945#c11 Enzo Matsumiya changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(duge@pre-sense.de | |), SHIP_STOPPER? --- Comment #11 from Enzo Matsumiya --- (In reply to Moritz Duge from comment #10)

Is there anything else I can do here to bring this forward?

Yes. Testing Leap 15.3 (and Tumbleweed, if possible) would be a good start. If it still fails, please provide debug logs + pcap. Thanks. -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1194945 https://bugzilla.suse.com/show_bug.cgi?id=1194945#c13 Enzo Matsumiya changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |SHIP_STOPPER?, CCB_Review? --- Comment #13 from Enzo Matsumiya --- (In reply to Moritz Duge from comment #12)

As said before, I already tested Leap 15.3.

(In reply to Moritz Duge from comment #5)

...

[...] 1. Both problems ("umount" and "df") are still present in openSUSE-15.3!

Ah sorry I missed it, too many bugs...

Meanwhile I even tested the Leap 15.4 Beta kernel version 5.14.21-150400.11.2. And the bug is also still present there.

Ok, I still can't reproduce. I built a kernel with HEAD 14302ee3301, and still couldn't reproduce. Without a pcap it's really hard to tell the details what the server is responding with (*). I'm using a Windows Server 2019 file server share, and I don't have easy access to a NetApp appliance to try this. I'm mounting this as a AD-DC user (kerberos), which has read-only rights on the share, and RW on the directory. Do you have any more details to add about the share settings? Apologies for the long back-and-forth here, but without reproducing the bug and without more details, it's hard for me to even guess where to begin. (*) - if you could anonymize the pcap and share only smb2 packets, that should do -- You are receiving this mail because: You are on the CC list for the bug.