Bug 2106087 - Kernel 5.18.10-200 Breaks Samba Client
Summary: Kernel 5.18.10-200 Breaks Samba Client
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 36
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-07-11 18:21 UTC by dc.hart
Modified: 2022-07-23 18:35 UTC (History)
20 users (show)

Fixed In Version: kernel-5.18.13-200.fc36
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-07-13 18:51:23 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
request and response of failed request (652 bytes, application/octet-stream)
2022-07-13 14:28 UTC, Georg Müller
no flags Details
request and response of working request (848 bytes, application/octet-stream)
2022-07-13 14:29 UTC, Georg Müller
no flags Details

Description dc.hart 2022-07-11 18:21:08 UTC
User-Agent:       Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.0.0 Safari/537.36
Build Identifier: 

Attempts to mount a samba share returns the error message "VFS: cifs_mount failed w/return code = -22"

This worked on July 10. The only thing that could have affected this was the kernel update on that day, which I did not load until today (July 11).

I tested the server with an Android client and everything works as expected.

Reproducible: Always

Steps to Reproduce:
1. sudo mount -a
fstab=
//192.168.1.6/WD   /home/xxx/shield   cifs  username=xxxx.xxxx.xxxx,password=xx-xxx-xxxx,noatime
Actual Results:  
CIFS: Attempting to mount \\192.168.1.6\WD
CIFS: VFS: cifs_mount failed w/return code = -22

Comment 1 Justin M. Forbes 2022-07-12 22:26:40 UTC
What is the samba server running? This patch originally came in with 5.18.8 and I reverted it until the discussion upstream confirmed that it was an issue with debian's samba server that was fixed some time ago, and not an issue with the kernel.  https://lore.kernel.org/linux-cifs/CAH2r5mv5bFG2tAEtbft-Zo+2jOqFfpr9B9TtWpgc5jhR-OiaZQ@mail.gmail.com/T/#t should have the discussion, and a workaround until the server if fixed.

Comment 2 Georg Müller 2022-07-13 14:28:47 UTC
Created attachment 1896794 [details]
request and response of failed request

there are two extra 0 bytes at the end of the request packet

Comment 3 Georg Müller 2022-07-13 14:29:23 UTC
Created attachment 1896795 [details]
request and response of working request

Comment 4 Georg Müller 2022-07-13 14:31:25 UTC
I compared the two Protocol Negotiate Requests (see attached PCAPs) and the failing request has two additional null bytes at the end of the request message.

Comment 5 Justin M. Forbes 2022-07-13 18:51:23 UTC
Again, read the link I posted, the kernel is not going to revert this. The server needs to be fixed, and there is a work around.

Comment 6 Georg Müller 2022-07-13 20:47:27 UTC
Remembering Linus' stance on regressions, even if behavior is correct and the bug is elsewhere, the problem might be fixed in the kernel.

The problem, for example, concerns all Synology Diskstations, and finding the reason why this fails is not really straight forward, and a lot more might run into it.

A kernel fix could just send the parameters in different order or strip the trailing bytes...

Comment 7 Georg Müller 2022-07-13 22:02:36 UTC
There is a patch on linux-cifs which restores the old order to avoid having the hostname at the end:

https://lore.kernel.org/linux-cifs/ed25591c-e62e-dcee-6df3-0530ef2ac555@gmail.com/T/#m8b190ef312503d91a65660406cc62c60fc81ce8d

Comment 8 Fedora Update System 2022-07-22 20:55:35 UTC
FEDORA-2022-311e6b1153 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-311e6b1153

Comment 9 Fedora Update System 2022-07-23 02:00:07 UTC
FEDORA-2022-311e6b1153 has been pushed to the Fedora 36 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 10 dc.hart 2022-07-23 18:35:26 UTC
Late last night my toy updated to 5.18.13-200.fc36.x86_64. The problem no longer exists.


Note You need to log in before you can comment on or make changes to this bug.