User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/188.8.131.52 Safari/537.36
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.
Steps to Reproduce:
1. sudo mount -a
//192.168.1.6/WD /home/xxx/shield cifs username=xxxx.xxxx.xxxx,password=xx-xxx-xxxx,noatime
CIFS: Attempting to mount \\192.168.1.6\WD
CIFS: VFS: cifs_mount failed w/return code = -22
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.
Created attachment 1896794 [details]
request and response of failed request
there are two extra 0 bytes at the end of the request packet
Created attachment 1896795 [details]
request and response of working request
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.
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.
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...
There is a patch on linux-cifs which restores the old order to avoid having the hostname at the end:
FEDORA-2022-311e6b1153 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-311e6b1153
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.
Late last night my toy updated to 5.18.13-200.fc36.x86_64. The problem no longer exists.