After a recent update of gentoo-sources from 5.14.15 to 5.15.0, bringing in my existing .config and running genkernel to produce a new 5.15.0 kernel and rebooting to us that kernel, I'm unable to browse shares on an older media player using CIFS 1.0. Reverting to the 5.14.15 kernel via reboot resolves the issue. Reproducible: Always Steps to Reproduce: I have an /etc/fstab entry like: //mede8er/mede8er /mnt/mede8er-smb cifs noauto,guest,users,uid=daf,gid=daf,iocharset=utf8,vers=1.0,nobrl 0 0 1. under 5.14.15, as a regular user, `mount /mnt/mede8er-smb` - mount succeeds 2. reboot to 5.15.0, as a regular user, `mount /mnt/mede8er-smb` - mount fails I see the following in /var/log/syslog: Nov 3 08:00:00 nea kernel: CIFS: VFS: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Nov 3 08:00:00 nea kernel: CIFS: Attempting to mount \\mede8er\mede8er Nov 3 08:00:00 nea kernel: CIFS: VFS: \\mede8er failed to connect to IPC (rc=-6) Nov 3 08:00:00 nea kernel: CIFS: VFS: cifs_mount failed w/return code = -6 When I compare kernel configuration for the two kernels, filtering for CIFS, the only difference I see is that the config option CONFIG_CIFS_WEAK_PW_HASH has been removed - I can't select it in `make nconfig` any more and it doesn't appear in the new .config I'm not sure if it's properly related, but I came across this: https://x-lore.kernel.org/linux-cifs/20210813195644.937810-3-lsahlber@redhat.com/ which seems to suggest that the logic should be rolled up and selected by CONFIG_CIFS_ALLOW_INSECURE_LEGACY=y (which is set in both kernels) I'm not sure if this is something that I should be reporting elsewhere? Please advise. Actual Results: Can't mount old CIFS 1.0 media player shares any more under kernel 5.15.0 (gentoo-sources) Expected Results: I should still be able to mount the old CIFS 1.0 shares because I've enabled CONFIG_CIFS_ALLOW_INSECURE_LEGACY=y in my kernel config.
Created attachment 748719 [details] full kernel config for 5.14.15
Created attachment 748722 [details] full kernel config for 5.15.0
I'm also not sure about setting the importance for this - it's a blocker for me to use 5.15.0, but 5.15.0 (gentoo-sources) is ~amd64 and I have my older 5.14.15 still installed
Does the output of this show anything in 5.15 ? findmnt --verify --verbose
`findmnt --verify --verbose` reports for this mount: /mnt/mede8er-smb [ ] target exists [ ] FS options: guest,uid=daf,gid=daf,iocharset=utf8,vers=1.0,nobrl [ ] userspace options: noauto,users [ ] do not check //mede8er/mede8er source (pseudo/net) [ ] do not check //mede8er/mede8er FS type (pseudo/net) attempting `mount /mnt/mede8er-smb` returns: Retrying with upper case share name mount error(6): No such device or address Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg) dmesg reports: [ 239.024504] Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers [ 239.024505] CIFS: VFS: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers [ 239.024508] CIFS: Attempting to mount \\mede8er\mede8er [ 239.205576] CIFS: VFS: \\mede8er failed to connect to IPC (rc=-6) [ 239.211939] CIFS: VFS: cifs_mount failed w/return code = -6 [ 239.211971] Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers [ 239.211972] CIFS: VFS: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers [ 239.211987] CIFS: Attempting to mount \\MEDE8ER\MEDE8ER [ 239.237105] CIFS: VFS: \\MEDE8ER failed to connect to IPC (rc=-6) [ 239.243201] CIFS: VFS: cifs_mount failed w/return code = -6
Update: issue remains in 5.15.1 (I'm not sure where to check for the changelog, so I thought I'd just test and I still can't connect to CIFS 1.0 shares with 5.15.1)
You have no sec=<something>. Is it trying to use ntlm ? ntlm was removed in 5.15 [1] [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=76a3c92ec9e0668e4cd0e9ff1782eb68f61a179c
As you've noted, I'm not setting `sec=` on the fstab line. According to `man mount.cifs` the default should be ntlmssp. I tried setting `sec=none` - which worked fine under 5.14.15 - and then rebooted to 5.15.2, where the mount still fails, with the same errors being produced as before.
update: still persists in 5.15.3
Created attachment 761299 [details, diff] SMB1 NTLM backport for kernel 5.15.12 I can't speak to this exact issue, but I needed NTLM support, so I backported the removed CIFS support into a patch that works great on 5.15.12. I've attached it to this issue, in case any future folks want this support added back into the kernel.
As upstream no longer supports this in 5.15, closing this bug.
Thanks for the patch Upstream, I raised https://bugzilla.kernel.org/show_bug.cgi?id=215375 and it appears as if someone _might_ care, so I'm waiting on a reply there - the commentary so far is that this isn't an upstream abandonment as there was confusion as to why cifs 1.0 shares stopped working after commit 18d04062f83b3eedb64e9f64ede26ee83ae7f152. I'm not sure if that should affect the status of this report.
(In reply to Davyd McColl from comment #12) > Thanks for the patch > > Upstream, I raised https://bugzilla.kernel.org/show_bug.cgi?id=215375 and it > appears as if someone _might_ care, so I'm waiting on a reply there - the > commentary so far is that this isn't an upstream abandonment as there was > confusion as to why cifs 1.0 shares stopped working after commit > 18d04062f83b3eedb64e9f64ede26ee83ae7f152. I'm not sure if that should affect > the status of this report. Excellent, we'll keep an eye on the upstream bug and look at potential backports of any changes.
Unfortunately, the patch provided by Robert Schultz doesn't apply cleanly any more as of 5.15.80: Hunk #1 FAILED at 3702. 1 out of 1 hunk FAILED -- saving rejects to file fs/cifs/connect.c.rej patching file fs/cifs/fs_context.c patching file fs/cifs/fs_context.h patching file fs/cifs/sess.c Hunk #1 succeeded at 826 (offset 28 lines). Hunk #2 succeeded at 974 (offset 28 lines). Hunk #3 succeeded at 1702 (offset 28 lines). patching file fs/cifs/smbencrypt.c [ !! ] * ERROR: sys-kernel/gentoo-sources-5.15.80::gentoo failed (prepare phase): * patch -p1 failed with /etc/portage/patches/sys-kernel/gentoo-sources/cifs_smb1_ntlm_backport.patch * * Call stack: * ebuild.sh, line 122: Called src_prepare * environment, line 1898: Called kernel-2_src_prepare * environment, line 1459: Called eapply_user * environment, line 773: Called eapply '/etc/portage/patches/sys-kernel/gentoo-sources/cifs_smb1_ntlm_backport.patch' * environment, line 736: Called _eapply_patch '/etc/portage/patches/sys-kernel/gentoo-sources/cifs_smb1_ntlm_backport.patch' * environment, line 674: Called __helpers_die 'patch -p1 failed with /etc/portage/patches/sys-kernel/gentoo-sources/cifs_smb1_ntlm_backport.patch' But fortunately, on the upstream kernel issue (https://bugzilla.kernel.org/show_bug.cgi?id=215375) there appears to have been a fix in the 6.x branch. Is there any possibility of getting that back-ported to 5.15?
update: I installed 6.0.11 and the upstream fix is in-place: CIFS 1.0 guest shares are mountable. So either stay on 5.15.75 with the patch here, or update to 6.0.11+ Thanks again for the patch.
(In reply to Davyd McColl from comment #15) > update: I installed 6.0.11 and the upstream fix is in-place: CIFS 1.0 guest > shares are mountable. So either stay on 5.15.75 with the patch here, or > update to 6.0.11+ > > Thanks again for the patch. I can look to backport the patch to 5.15.X, I will take a look today
(In reply to Mike Pagano from comment #16) > (In reply to Davyd McColl from comment #15) > > update: I installed 6.0.11 and the upstream fix is in-place: CIFS 1.0 guest > > shares are mountable. So either stay on 5.15.75 with the patch here, or > > update to 6.0.11+ > > > > Thanks again for the patch. > > I can look to backport the patch to 5.15.X, I will take a look today Is this all we need? https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/cifs?id=2f6f19c7aaad5005dc75298a413eb0243c5d312d
I'm not sure at all ): What I can report is that 6.1.0 is broken wrt CIFS in new and fantastic ways :| mounting and listing files is fine, but any attempt to transfer files ends up stalling - my own software (https://github.com/fluffynuts/bitsplat/) syncs after every write to produce more accurate ETAs and will stall almost immediately. Something like the dolphin file browser will appear to transfer a bit, but it's obviously just filling caches - and will stall after a short time )':
I can report that on kernel 6.1.1 I cannot mount cifs version 1.0 shares while on 6.0.11 it works. No changes in settings. The only difference in logs is that on 6.1.1 the following appears when automounting via fstab: CIFS: VFS: bogus file nlink value 0 If I try to mount via command line I get: mount error 20 Not a directory
Can you do a bisect between 6.0.11 and 6.1.1 ?
fwiw, I first saw the new regression(*) in 6.1.0 and I don't have it in 6.0.15, so that might narrow the search a little if no-one can check it tonight, I might be able to tomorrow, tho my experience from last time is that it will take a while :| * in 6.1.0+, I can mount without error, but file i/o stalls (my sync program just gets stuck - but that attempts an fsync on every chunk - dolphin will appear to copy a bit and then stall, so it's likely just filling buffers). If I try to touch a new file on the mounted share, touch will segfault!
(In reply to Mike Pagano from comment #20) > Can you do a bisect between 6.0.11 and 6.1.1 ? Sorry for late reaction. I am not a developer so I had to first understand what bisection exactly means. Now that I know it might be bit time consuming and interacting with my normal use of computer I will first try 6.1.2 and if it persists I will try with as close kernels as possible in spare time. And of course report if I find anything useful. Thanks for the idea.
6.1.2 installed - same result: can mount a cifs 1.0 share, but attempting to touch a new file on that share segfaults I guess this really does need a bisect and to be pushed up to kernel devs. I'm a little frustrated at something that worked for 2 decades being broken, but I guess that's just how the cookie crumbles.
ok, so this is quite interesting: 6.0.15 - no problems 6.0.16 - can mount, touch segfaults, my sync app stalls (probably on first fsync) So there's quite a tight range there - 6.0.15 works fine, 6.0.16 is properly broken.
https://lore.kernel.org/all/CAJjP=Bt52AW_w2sKnM=MbckPkH1hevPMJVWm_Wf+wThmR72YTg@mail.gmail.com/#t If this is on longer supported by upstream, not sure what we can do here.
fwiw, 6.1.8 appears to be working properly again, after testing a patch on 6.0.16 ( https://bugzilla.kernel.org/show_bug.cgi?id=216889 ). Upstream appears to be supporting older CIFS clients if they use guest credentials - which suits my purpose - but I'm not sure if they will support older authentication schemes.
(In reply to Davyd McColl from comment #26) > fwiw, 6.1.8 appears to be working properly again, after testing a patch on > 6.0.16 ( https://bugzilla.kernel.org/show_bug.cgi?id=216889 ). Upstream > appears to be supporting older CIFS clients if they use guest credentials - > which suits my purpose - but I'm not sure if they will support older > authentication schemes. Great news, glad at least guest mode works. Thanks for reporting.
I can (albeit late) confirm that 6.1.8 fixes the mounting of cifs vers=1.0 shares for me as well. Thanks to all.
