After 5.15.0, I'm unable to mount a CIFS 1.0 share from a media player which I cannot update (vendor no longer provides updates). Original issue is logged here: https://bugs.gentoo.org/821895, with the most interesting bits probably being: 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-5}, 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 I see that there was some cleanup against CIFS and weaker auth algorithms here: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=76a3c92ec9e0668e4cd0e9ff1782eb68f61a179c Now, I'm assuming good reasons for the change, but have to ask: 1. Is it intended that I should not be able to connect to these older devices any more? 2. If so, does anyone know of an alternative method to do so (eg user-space filesystem - I've tried smbnetfs under 5.15.5 to no avail, but perhaps I'm just doing something wrong) If this is intended behavior, it puts me (and quite likely others) in the position where kernel upgrades on one machine are controlled by the capabilities of another machine, unless there's a reasonable alternative (ie, 2). If it is intended that I should still be able to connect to these shares, I'd appreciate any pointers in the right direction. Kernel configurations are posted at the original issue report, but I can repost here if preferred. I've reposted here because the original issue seems to have stalled and I'm running hardware (navi amdgpu) which may well benefit, stability-wise, from keeping to the latest kernel, so I'd prefer to do so.
Apologies, have also tested with 5.15.10 and the issue persists, contra to my original posting of 5.15.{0-5}
A question to make me understand this better. The Kconfig text removed by the patch you link to states: - Modern CIFS servers including Samba and most Windows versions - (since 1997) support stronger NTLM (and even NTLMv2 and Kerberos) - security mechanisms. Is your media player this old? Also: have you tried reverting the change to ensure it's the root of the problem? Alternatively, try to compile the kernel right before the commit and the one with it to check if this really is the issue -- or do a full bisection between 5.14..5.15.
1. This is a mede8er 600x3d, last updated in APril 2016, and apparently they went with the bare minimum for samba shares. 2. 5.14.15 and below work fine connecting - indeed, what I've been doing is keeping the older kernel around just so that sync tasks from my pc can mount & transfer files to the media player. As soon as 5.15.0 came down on my machine, and up to the current 5.15.10, I've been unable to mount shares from that media player at all. Unfortunately, the last gentoo-sources atom for 5.14 was 5.14.15, though I see at kernel.org that there were releases up to .19 I can do the check you've asked for when I have a moment, if it can be helpful, but I haven't seen any other changes in that area - not that I did an exhaustive search though.
I'm building commit 18d04062f83b3eedb64e9f64ede26ee83ae7f152 (the parent to the mentioned one) right now and it's making me think that the problem comes in some time later - genkernel is reporting that the version at this commit is 5.14.0-rc7, so if versioning holds up consistently, I would have expected the version here to be > 5.14.15 ): bisecting is going to be a long and arduous process ):
Ok, 2.5 hours of bisecting later and I can confirm that the culprit is [76a3c92ec9e0668e4cd0e9ff1782eb68f61a179c] cifs: remove support for NTLM and weaker authentication algorithms The commit before works fine, this commit prevents me from mounting the smb shares on my mede8er 600x 3d.
I feel like I need to ask why the auth mechanisms were removed instead of rather put behind config defaulted off? 27 million lines of code in the kernel, removing this code this isn't saving much. I understand the desire to improve security, but the big draw to Linux (at least for me) is the freedom to make my machine do what I want, not what someone else thinks it should do. OTOH, perhaps there's good reasoning here and I just don't understand it.
CC'ing Ronnie Sahlberg who made the commit.
Mike Pagano has kindly provided a patch to revert this behavior for now (https://bugs.gentoo.org/attachment.cgi?id=761299), so at least I can use the latest kernel with updated drivers. If there's anything I can do to help further with this, please let me know.
(In reply to Davyd McColl from comment #8) > If there's anything I can do to help further with this, please let me know. I guess it would be a lot better to get this discussed on the list, as bugzilla is bad choice for most subsystems, as explained in https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html But maybe waiting a few more days with that might be worth it, maybe Ronnie shows up and just was AFK due to the festive season.
NTLM was removed because it it insecure and we are moving away from insecure options in cifs. When it comes to NTLM, it was replaced by NTLMv2 decades ago and is not supported in SMB2/3 at all. In the kernel, some of the crypto dependencies that NTLM depends on are scheduled for removal, thus keeping it will soon require to import and carry replacement crypto and rewrite the APIs that are used, as the crypto will no longer be available via the standard kernel API. With this extra maintenance overhead, as well as that we are moving away from all the insecure options that give CIFS a bad name, we decided to just remove it completely. The work to remove or disable insecure and obsolete parts of CIFS is ongoing. This is something that is better to discuss on the mailing list.
I'd appreciate guidance as to _which_ mailing list I should bring this up in. The device I'm trying to connect to is a mede8er med600x 3d, last patched in 2018, it runs Linux and this is the only network protocol it supports for transferring files to it. I totally understand the desire to clean up old code, but in a code-base that is nearly 28 million lines large, on a kernel which still supports some really old and obscure hardware behind configuration flags, it doesn't make sense (to me) that this facility should be completely removed. I would totally understand if it were put behind configuration, defaulted off, but the current situation is that I'm having to reverse the patch at each build and I'm sure that at some point, my reversal patch won't work against changed upstream code, at which time, my choices are to abandon a device which works just fine or run an old VM to support network transfers to this machine, bearing in mind that synchronisation between my main machine and this player happens throughout the day as my main machine downloads media and pushes it to the media player, archiving media that has been watched. Certainly I can't be the only person affected by this, though I understand that it's probably not a massive audience.
(In reply to Davyd McColl from comment #11) > I'd appreciate guidance as to _which_ mailing list I should bring this up in. https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html provides some hints. In the end you afaics want to include at least these addresses: To: lsahlber@redhat.com, Steve French <stfrench@microsoft.com> CC: linux-cifs@vger.kernel.org, linux-kernel@vger.kernel.org, regressions@lists.linux.dev, regressions@leemhuis.info BTW, maybe this text currently under review is of interest for you (esp. the "Does the 'no regression' rule apply if I seem to be the only person in the world that is affected by a regression?" section): https://lore.kernel.org/linux-doc/7b71a1262b8b72d30154203bb14f00db7d4170ef.1641203216.git.linux@leemhuis.info/ But fwiw, this afaics is one of those tricky issues where not fixing *might* be the right things to do. But maybe some solution can be found to make everyone happy.
(In reply to Davyd McColl from comment #11) > Certainly I can't be the only person affected by this, though I understand > that it's probably not a massive audience. No, you are not. I'm also affected. I run several Win2k machines under QEMU that I map to from my host Linux OS, which stopped working once I updated to Kernel 5.15.12. That's why I made the patch on the Gentoo thread to backport this feature back into the kernel. I'm not aware of any other method under linux to mount CIFS NTLM shares (for example, no FUSE driver that I'm aware of). So if the decision stands to keep this removed from the kernel, I'll just keep patching it back into every future kernel release. Sorry for posting this response here, it seems the preferred method is the regressions mailing list, but I wasn't able to subscribe to it, mailing list server replied with a "Blocked by SpamAssassin" response.
I've attempted to send an email to the above addresses, but two (as far as I can tell) have bounced it because it was unfortunately encoded as html, even though there was no formatting involved. I'll try to send again, though the two email clients I use (Mailspring and Mailbird) don't seem to surface a way to send a mail as plaintext.
(In reply to Davyd McColl from comment #14) > I've attempted to send an email to the above addresses, but two (as far as I > can tell) have bounced it because it was unfortunately encoded as html I just replied as plain text with a full quote, that way everyone should see it.
It's not just old media servers. Many routers serve network-attached USB disks but older models (like mine) only offer cifs 1.0. I too do not understand the decision to cut off support for legacy cifs servers. Is there a strong technical motivation for this? Is the existence of the old code seriously impeding forward progress? Are those "crypto depdendencies" to be removed simply no-longer-secure, or are they actively causing trouble somehow? Suggest renaming old algos/apis "insecure_xxx" to make their status crystal clear, and maybe #ifdef the code so embedded kernels can save memory be omitting them Please don't jettison support for legacy hardware without at least mildly compelling reasons, and then only after lots of advance notice so people can replace their to-be-orphaned hardware in advance.
Here only a few people will notice your comment; your opinion is way more likely to get heard my joining the mailing discussion about this, where Linus himself weighted in: https://lore.kernel.org/all/CAHk-=wjSBvRk-ksUBOiQzJd=e19UZKvOSZs1UHahK5U0QVh6RQ@mail.gmail.com/ Feel free to reply there.
After kernel update in my netbook "music player" i encountered the same problems with mounting shares that was not possible to fix from userspace via config,options and etc. So i HAD to go that deep right to the debug logs of client/server and kernel cifs module sources to dig the roots of the problem. [37966.536917] CIFS: Status code returned 0xc00000cc NT_STATUS_BAD_NETWORK_NAME [37966.536937] CIFS: fs/cifs/netmisc.c: Mapping smb error code 0xc00000cc to POSIX err -6 [37966.536960] CIFS: fs/cifs/connect.c: VFS: leaving cifs_setup_ipc (xid = 1556) rc = -6 [37966.536977] CIFS: VFS: \\192.168.0.11 failed to connect to IPC (rc=-6) Looks like code 0xc00000cc NT_STATUS_BAD_NETWORK_NAME means "The specified share name cannot be found on the remote server". When looking at the server side logs prior to that: [2022/07/21 04:12:58.522776, 3] smbd/service.c:343(find_service) checking for home directory 尀昀爀攀攀瀀挀尀䤀倀䌀␀ gave (NULL) [2022/07/21 04:12:58.522833, 3] smbd/service.c:444(find_service) find_service() failed to find service 尀昀爀攀攀瀀挀尀䤀倀䌀␀ Surpisingly, there really was no share with that "china style" names on the server. After some guessing i find out that client passed path re-encoded in UTF16 instead of UTF8. This behavior is based on the "capabilities" define in protocol negotiation, so it's not possible to disable it from userspace. I build the modified kernel cifs module (based on my kernel sources) with the following patch: @@ -3826,18 +3826,10 @@ if (ses->capabilities & CAP_DFS) { smb_buffer->Flags2 |= SMBFLG2_DFS; } - if (ses->capabilities & CAP_UNICODE) { - smb_buffer->Flags2 |= SMBFLG2_UNICODE; - length = - cifs_strtoUTF16((__le16 *) bcc_ptr, tree, - 6 /* max utf8 char length in bytes */ * - (/* server len*/ + 256 /* share len */), nls_codepage); - bcc_ptr += 2 * length; /* convert num 16 bit words to bytes */ - bcc_ptr += 2; /* skip trailing null */ - } else { /* ASCII */ - strcpy(bcc_ptr, tree); - bcc_ptr += strlen(tree) + 1; - } + + strcpy(bcc_ptr, tree); + bcc_ptr += strlen(tree) + 1; + strcpy(bcc_ptr, "?????"); bcc_ptr += strlen("?????"); bcc_ptr += 1; And now the smbv1 share mounts successfully without problems! I hope it would help someone who wants to build the working cifs module to restore the functionality.
Created attachment 301473 [details] cifs smb1 ntlm backport patch for kernel 5.18.8 I've went ahead and attached my updated CIFS/SMB1/NTLM backport patch that I updated for Kernel 5.18.8 Just in case anyone else out there needs this removed functionality.
+1 to bring back as an option. General boot disk used for backups and disaster recovery needs to support latest hardware and old hardware for those internal control system and internal NAS with older protocols.
Installed kernel 5.18.15, patched <connect.c> file in fs/cifs module with my previous patch removing utf8 to utf16 conversion & compiled cifs.ko - tested and confirmed that smbv1 working fine again. I think this patch should be incorporated at least as a mount option/flag like "no_utf_conv", example : if ((ses->capabilities & CAP_UNICODE) && (ctx->no_utf_conv == NULL)) Please return the possibility to mount smbv1 shares without the need of recompiling the kernel module after every update!
I'm glad I found this discussion thread. I am also affected. I use SMB1 to connect to an older multimedia device (dreambox DM800HD PVR, a DVB-C/S/T receiver and disk recorder, Linux-based) and suffer as well from the problem discussed in this bug ticket. After reading this thread, the one at lore.kernel.org, and after looking at the patch causing the issue, I think I can bring an additional piece of information to the discussion. IMHO there acutally is a regressing from the patch 76a3c92ec9e0668e4cd0e9ff1782eb68f61a179c which leads in some situations to a violation of the SMB1 protocol. In my setup I have the server configured in share mode, i.e. regardless of whether I log in with any user/pass or without a user (using "guest" or "sec=none" in mount.cifs), the "Session Setup AndX Response" logs me in as "Guest", a mode where no password is expected. This works as intended and is similar to Davyd's situation of using mount option "guest". It is the following "Tree Connect AndX Request" which with Linux kernel 5.15 causes the problem. User "CIFS user" had already observed the "chinese" characters in the server log. I observe the same, and I like to explain my findings in more detail. My server (Samba 3.0.37) announces that it talks Unicode on the wire, thus SMBFLG2_UNICODE is set. This means that according to SMB1 specification the password field must be padded such that the following path field starts at a 2-byte boundary from the start of the SMB Header, and the path will be written on wire in UTF-16LE. At least with guest mode, it is expected, that the password field is empty. Unfortunately, with Linux kernel 5.15 the empty password is not padded correctly, thus the path is written on wire one byte too early. A path of "\\10.1.1.9" is encoded in UTF-16LE as "5c 00 5c 00 31 00 ...". When reading the path from the data structure, due to the missing padding byte, the server misses the first byte of the path and only reads a path of UTF16LE "00 5c 00 31 ...", which yields the "chinese" character U+5C00 followed by U+3100. I was able to correlate the "chinese" path reported in my server log to this requested path shifted by 1 byte. I feel the discussion around patch 76a3c92ec9e0668e4cd0e9ff1782eb68f61a179c is a lot on whether or not some authentication methds should or should not be used. But in my case and I guess for others as well, where we use the "guest" mode and no password at all, we do not need the deprecated authentication methods, we only require the Linux kernel to handle this "guest" mode correctly. It looks like after that patch and when using Unicode on the wire and when the password is empty, the Linux kernel would create a wrong "Tree Connect AndX Request" data structure. My suspicion is that it is cased by the deletion of these lines in the patch, which to my understanding would have added the 1-byte padding and an empty password: if (ses->capabilities & CAP_UNICODE) { /* must align unicode strings */ *bcc_ptr = 0; /* null byte password */ bcc_ptr++; } If I understood correctly, user "CIFS user" has proposed a workaround by ignoring the unicode capability and simply writing the "Tree Connect AndX Request" as UTF-8 indicating that this request does not have a unicode capability. I would prefer a solution where the unicode capability is kept and the currently missing 1-byte padding is restored to that the path is correctly aligned according to SMB1 specification. I would expect that then SMB1 continues to work for those use cases where no authentication is needed, like in the "guest" mode some of us use. I would not be able to patch a kernel or compile and test a kernel, but I hope with the analysis someone more capable could perhaps confirm that this 1-byte-off is a probably unintended bug introduced by the original path and introduce the required correction. My test setup: client: Linux dm800 2.6.18-7.4-dm800, Samba 3.0.37 server: Linux nas 5.15.0-46-generic #49-Ubuntu SMP sudo mount.cifs //10.1.1.9/Harddisk /mnt -o vers=1.0,ro,uid=0,forceuid,gid=0,forcegid,actimeo=60,guest,sec=none trace captured via tcpdump, available on request (but how/where to upload?) References: MS-SMB1 protocol https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-smb/fd2a8346-9414-40e2-81b1-ed294f9768ea refers mainly to CIFS Protocol: https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-cifs/d416ff7c-c536-406e-a951-4f04b2fd1d2b CIFS as PDF: https://winprotocoldoc.blob.core.windows.net/productionwindowsarchives/MS-CIFS/%5bMS-CIFS%5d.pdf See on page 296 for Pad and Path fields.
I can not reproduce or test, but Carsten makes a good point in #22. Can someone try this small patch ? diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c index 3da5da9f16b0..cab1be85dfa4 100644 --- a/fs/cifs/connect.c +++ b/fs/cifs/connect.c @@ -3926,12 +3926,11 @@ CIFSTCon(const unsigned int xid, struct cifs_ses *ses, pSMB->AndXCommand = 0xFF; pSMB->Flags = cpu_to_le16(TCON_EXTENDED_SECINFO); bcc_ptr = &pSMB->Password[0]; - if (tcon->pipe || (ses->server->sec_mode & SECMODE_USER)) { - pSMB->PasswordLength = cpu_to_le16(1); /* minimum */ - *bcc_ptr = 0; /* password is null byte */ - bcc_ptr++; /* skip password */ - /* already aligned so no need to do it below */ - } + + pSMB->PasswordLength = cpu_to_le16(1); /* minimum */ + *bcc_ptr = 0; /* password is null byte */ + bcc_ptr++; /* skip password */ + /* already aligned so no need to do it below */ if (ses->server->sign) smb_buffer->Flags2 |= SMBFLG2_SECURITY_SIGNATURE; -- 2.35.3
I ran into this bug today while trying to access a SMB1 share on an old BSD server that IT is afraid to upgrade out of fear other stuff will break that they won't be able to fix. Spent over 4 hours trying to figure out why everything else could mount the share perfectly fine & not this machine. Server reports the same Chinese share names are trying to be accessed as above - in my case, 尀戀愀礀挀椀琀礀⸀最爀愀昀昀尀猀栀愀爀攀搀 - when the actual share I'm trying to access is 'shared'. Machine is Ubuntu 22.04.1 installed 2 weeks ago with kernel 5.15.0-48-generic Interestingly, the command smbclient --no-pass --list=10.20.10.10 --option='client min protocol=NT1' shows all the available shares on this machine just fine. Is there any other mount command or package I can install to mount the share in the same manner the smbclient program uses??? If someone can explain to me how to apply the patch in this comment, I will attempt to do it and report the results. Jim (In reply to Ronnie Sahlberg from comment #23) > I can not reproduce or test, but Carsten makes a good point in #22. > Can someone try this small patch ? > > diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c > index 3da5da9f16b0..cab1be85dfa4 100644 > --- a/fs/cifs/connect.c > +++ b/fs/cifs/connect.c > @@ -3926,12 +3926,11 @@ CIFSTCon(const unsigned int xid, struct cifs_ses > *ses, > pSMB->AndXCommand = 0xFF; > pSMB->Flags = cpu_to_le16(TCON_EXTENDED_SECINFO); > bcc_ptr = &pSMB->Password[0]; > - if (tcon->pipe || (ses->server->sec_mode & SECMODE_USER)) { > - pSMB->PasswordLength = cpu_to_le16(1); /* minimum */ > - *bcc_ptr = 0; /* password is null byte */ > - bcc_ptr++; /* skip password */ > - /* already aligned so no need to do it below */ > - } > + > + pSMB->PasswordLength = cpu_to_le16(1); /* minimum */ > + *bcc_ptr = 0; /* password is null byte */ > + bcc_ptr++; /* skip password */ > + /* already aligned so no need to do it below */ > > if (ses->server->sign) > smb_buffer->Flags2 |= SMBFLG2_SECURITY_SIGNATURE; > -- > 2.35.3
I can confirm that the removal of NTLMv1 auth also affects Apple time capsule 4th gen devices, latest firmware 7.8.1 (as of 04-oct-2022). I am unable to mount with "vers=1.0,sec=ntlm". I tried other sec options but no luck. The device is from 2012, works fine as wifi router and NAS, I feel no need to replace it as long as it works. I hope there are at least thousands of Apple time capsule users out there being affected by this change. I am OK with weaker security of NTLMv1, it would be nice to have option to enable it by simple means (like kernel module parameter/ Kconfig parameter), in official kernels itself.
Did anybody affected by this try Ronnie's patch and provide feedback? That afaics would be the next step needed to fix this for all or at least some users.
(In reply to The Linux kernel's regression tracker (Thorsten Leemhuis) from comment #26) > Did anybody affected by this try Ronnie's patch and provide feedback? That > afaics would be the next step needed to fix this for all or at least some > users. If you can point me to something explaining how to apply the patch on an Ubuntu system, I'm willing to try it and report back. (Last time I patched a kernel was well over a decade ago on Slackware running a 2.4 kernel, so what little I do remember about doing it is massively out of date.)
Same here, I try to test the patch on Ubuntu but I'm lacking a bit of guidance as I never did such thing before.
Maybe this helps: https://docs.kernel.org/process/applying-patches.html There are many pages on the web that explain this from a different angle.
I have compiled and tested 5.18.8-cifs_smb1_ntlm_backport.patch on Linux Mint 21 with ubuntu mainline kernel 5.18.8. I can now mount and access files on Apple time capsule, using "vers=1.0,sec=ntlm" cifs mount option. Haven't compiled 5.15.x or 5.19.x yet. But patch does apply successfully to 5.19.13 Ubuntu mainline source tree. General instructions for Ubuntu/Mint kernel compilation: https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel List of available Ubuntu/Mint mainline kernel sources: https://git.launchpad.net/~ubuntu-kernel-test/ubuntu/+source/linux/+git/mainline-crack/refs/tags Downlad your desired version: git clone --depth 1 --single-branch --branch 'cod/mainline/v5.18.8' 'git://git.launchpad.net/~ubuntu-kernel-test/ubuntu/+source/linux/+git/mainline-crack' cod/mainline/v5.18.8 cd cod/mainline/v5.18.8 Download patch: wget -O 5.18.8-cifs_smb1_ntlm_backport.patch https://bugzilla.kernel.org/attachment.cgi?id=301473 Verify patch: patch -p1 --dry-run <5.18.8-cifs_smb1_ntlm_backport.patch If dry run shows no errors, apply patch: patch -p1 <5.18.8-cifs_smb1_ntlm_backport.patch Configure kernel options: chmod a+x debian/rules debian/scripts/* debian/scripts/misc/* LANG=C fakeroot debian/rules clean LANG=C fakeroot debian/rules editconfigs Enable fs/cifs/"Support legacy servers which use weaker LANMAN security" fs/cifs/Kconfig option CIFS_WEAK_PW_HASH Build kernel: LANG=C fakeroot debian/rules binary-headers binary-generic binary-perarch Install debian packages generated in parent directory: sudo dpkg -i ../*.deb Reboot into new kernel using grub advanced menu
(In reply to Ganesh Ingle from comment #30) > git clone --depth 1 --single-branch --branch 'cod/mainline/v5.18.8' > 'git://git.launchpad.net/~ubuntu-kernel-test/ubuntu/+source/linux/+git/ > mainline-crack' cod/mainline/v5.18.8 /me wonders if that is a heavily modified ubuntu kernel, which would be a really bad base for testing
(In reply to The Linux kernel's regression tracker (Thorsten Leemhuis) from comment #31) > (In reply to Ganesh Ingle from comment #30) > > > git clone --depth 1 --single-branch --branch 'cod/mainline/v5.18.8' > > 'git://git.launchpad.net/~ubuntu-kernel-test/ubuntu/+source/linux/+git/ > > mainline-crack' cod/mainline/v5.18.8 > > /me wonders if that is a heavily modified ubuntu kernel, which would be a > really bad base for testing Vanilla kernels may give bunch of other problems in Ubuntu based systems. Every distribution has their own patchset, e.g Android. You should use your distribution's recommended kernel source tree to apply and test this NTLM patch. Desktops benefit most from cutting edge kernels. My browsing and video streaming service experience is better on 5.18.x / 5.19.x kernels, compared to 5.14. All other hardware is also working fine on 5.18 and 5.19 series. System feels more responsive. Ubuntu 20/21/22.x, Mint 20/21 based servers might need a more stable v5.15.x kernels e.g v5.15.72 is tagged stable here: https://git.launchpad.net/~ubuntu-kernel-test/ubuntu/+source/linux/+git/mainline-crack/tag/?h=v5.15.72 git clone --depth 1 --single-branch --branch 'cod/mainline/v5.15.72' 'git://git.launchpad.net/~ubuntu-kernel-test/ubuntu/+source/linux/+git/ mainline-crack' cod/mainline/v5.15.72 Older kernels <=5.14 don't have this issue in the first place.
(In reply to Ganesh Ingle from comment #32) > > Vanilla kernels may give bunch of other problems in Ubuntu based systems. Well, of course, but this bug-tracker is all about the upstream kernel. Any testing feedback you provide here with kernels that are not vanilla thus might *in the worst case* be considered irrelevant here and ignored(¹), as any changes applied by distributions like Ubuntu can cause all sorts of side-effects. (¹) if that's actually the case depends on the kernel, the patch, the testing performed, and the developer in question!
Since I just need a functioning system, I tried installing kernel 5.14.21 (the latest 5.14 I could find on the ubuntu site, which isn't supposed to suffer from this defect) from https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.14.21/amd64/ Unfortunately, the headers file won't install due to a missing dependency - libssl1.1 & apt refuses to install it. Looking around, this appears to not exist for 22.04; I've found people saying you can install a package of libssl1.1 built for an older version of Ubuntu, but this seems like a bad idea to me. I'll do it if there's no other solution though... like I said, I just need the system to work. Anyone know if this is possible or know of a fix / workaround to get a kernel installed that doesn't have this problem?
(In reply to Jim from comment #34) > Since I just need a functioning system, I tried installing kernel 5.14.21 > (the latest 5.14 I could find on the ubuntu site, which isn't supposed to > suffer from this defect) from > https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.14.21/amd64/ > Unfortunately, the headers file won't install due to a missing dependency - > libssl1.1 & apt refuses to install it. Looking around, this appears to not > exist for 22.04; I've found people saying you can install a package of > libssl1.1 built for an older version of Ubuntu, but this seems like a bad > idea to me. I'll do it if there's no other solution though... like I said, > I just need the system to work. > > Anyone know if this is possible or know of a fix / workaround to get a > kernel installed that doesn't have this problem? 5.14.x did install on my Linux Mint 21 (based on Ubuntu 22.04 I believe), and it doesn't have this NTLM issue. I used a tool called "mainline kernel installer". https://github.com/bkw777/mainline It is a free fork of paid Ukuu software for ubuntu.
(In reply to The Linux kernel's regression tracker (Thorsten Leemhuis) from comment #33) > (In reply to Ganesh Ingle from comment #32) > > > > Vanilla kernels may give bunch of other problems in Ubuntu based systems. > > Well, of course, but this bug-tracker is all about the upstream kernel. Any > testing feedback you provide here with kernels that are not vanilla thus > might *in the worst case* be considered irrelevant here and ignored(¹), as > any changes applied by distributions like Ubuntu can cause all sorts of > side-effects. > > (¹) if that's actually the case depends on the kernel, the patch, the > testing performed, and the developer in question! Well thats true in theory. But Ubuntu patches are mainly about packaging their .deb files and Kconfig options suited for Ubuntu's user base. The changes to core kernel features like file systems / networking may be minimal to none at best. So the testing done with those kernels does have some value to this tracker.
To give some backgound, Apple airport / time capsule range of wireless products were developed around 2008-2012. The latest 5th gen stopped production in 2018. They all use some old minimalistic version of FreeBSD, the samba server inside supports only NTLMv1 (v0.18 I believe) and smb protocol version 1.0. Apple's team is no longer there to support newer auth and protocol in firmware updates. Ideally they (Apple) should fix security holes in their products. MacOSX users use AFP protocol to access files, but Linux users are out of luck, AFP support is poor in linux. Microsoft windows 10+ users have option to enable NTLMv1/CIFS 1.0, in their policy management. So I think at least Linux distributions (if not kernel.org) should maintain this support as an admin option.
Never mind my previous comment from 14:37:53 - I figured it out. For the benefit of anyone monitoring or finding this thread, if you're like me and just want it to work, here's how I got it working on my Ubuntu 22.04 system - YMMV: I downloaded the following files: https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.14.21/amd64/linux-image-unsigned-5.14.21-051421-generic_5.14.21-051421.202111210831_amd64.deb https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.14.21/amd64/linux-modules-5.14.21-051421-generic_5.14.21-051421.202111210831_amd64.deb Started a terminal in that directory and ran: sudo dpkg -i linux-image-unsigned-5.14.21-051421-generic_5.14.21-051421.202111210831_amd64.deb linux-modules-5.14.21-051421-generic_5.14.21-051421.202111210831_amd64.deb Apparently, the headers (which is the only package needing an old version of libssl that the current version doesn't provide backwards compatibility for whatever reason) aren't actually required. When I rebooted, uname still reported I was running 5.15. Rebooted again and on the grub menu, arrowed down to Advanced Options for Ubuntu and hit enter. Picked the 5.14 kernel from this sub-menu and hit enter. System booted and uname reported it was running 5.14.21. More importantly, the file shares running 1.0 mounted perfectly - the comments above saying this kernel version doesn't suffer from this flaw are correct. :) Disclaimer - I'm just a regular guy who needed his system to work how it should. If you can't tell, I'm not a kernel developer and have no clue what else was changed from 5.14 to 5.15. I've no idea what using an older kernel might break or cause to malfunction, but my system seems fine since. I hope this bug is fixed so I can resume using the latest/greatest kernel, but at least my system is now working. I hope that this information helps save someone in the future some time/frustration. :) Hope the kernel developers don't take this to be insulting, but from the perspective of a regular user, it seems like removing stuff arbitrarily seems exactly like the kind of thing that annoys people at windoze... new OS patch and suddenly your existing stuff that worked before the patch doesn't work anymore. :( Ah well - at least there's a fairly simple workaround in the Linux world, even though it's hokey and difficult to find. (I was troubleshooting and searching online for over a week before stumbling across this thread.)
(In reply to Ganesh Ingle from comment #36) > But Ubuntu patches are mainly about packaging > their .deb files and Kconfig options suited for Ubuntu's user base. The > changes to core kernel features like file systems / networking may be > minimal to none at best. So the testing done with those kernels does have > some value to this tracker. The diffstat I got when I just compared linux-5.15.y with master-prep from https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/jammy tells a different story: 1800 files changed, 489148 insertions(+), 15575 deletions(-) But maybe I did something wrong or we are talking past each other; do you maybe mean a branch that is close to vanilla? We here can't now these things, there are lot's of distros out there. Whatever, we are getting off-topic.
(In reply to Jim from comment #38) > Hope the kernel developers don't take this to be insulting, [...] No, not at all, because... > removing stuff arbitrarily […] ...that is normally not done. In fact it's policy to not break things: https://docs.kernel.org/admin-guide/reporting-regressions.html The problem is: security is a concern here and sometimes compromises need to be found: https://lore.kernel.org/lkml/CAHk-=wjSBvRk-ksUBOiQzJd=e19UZKvOSZs1UHahK5U0QVh6RQ@mail.gmail.com/ We are not there yet and Ronnie tried to find one with the patch he posted, that's why I asked for testers.
(In reply to The Linux kernel's regression tracker (Thorsten Leemhuis) from comment #40) > (In reply to Jim from comment #38) > > > Hope the kernel developers don't take this to be insulting, [...] > > No, not at all, because... > > > removing stuff arbitrarily […] > > ...that is normally not done. In fact it's policy to not break things: > https://docs.kernel.org/admin-guide/reporting-regressions.html > > The problem is: security is a concern here and sometimes compromises need to > be found: > https://lore.kernel.org/lkml/CAHk-=wjSBvRk- > ksUBOiQzJd=e19UZKvOSZs1UHahK5U0QVh6RQ@mail.gmail.com/ > > We are not there yet and Ronnie tried to find one with the patch he posted, > that's why I asked for testers. I'm glad you didn't take it in a way I didn't intend... tried to phrase it best I could to not be insulting, but can see how some would be offended by my comment. (My first & only involvement with an open source project was ffmpeg back in college; they're rather touchy over there.) I do development myself, though not at an OS/kernel level, and understand that real-world end user perspectives can be lost on the people developing, which is why I used that analogy. If security is a concern for this specific version of the protocol, why not just require one more flag making the user acknowledge it isn't secure when mounting or in fstab? Really wish I could help get you what you exactly the feedback you asked for Thorsten, but I'm just not good enough with the nitty-gritty low level parts of linux anymore. :( Like I mentioned earlier, the last time I patched a kernel was in 2.4 over 15 years ago & that was only to fix a flaw in a video capture card driver IIRC. So much has changed since then & I've just had no real reason to keep up.
Android 13 seems to be getting on 5.15 kernel soon. There might be some more affected users when it hits markets. Anyone willing to volunteer a backport patch for Android could find this useful: https://android.googlesource.com/kernel/common/+/refs/heads/android13-5.15 Since kernel.org seems not to be willing to maintain this old code for reasons of security, maintainer's burden and code complexity, I am wondering what would be right place to document the work-arounds and patch procedures shared by tester users. The current working patch could keep the niche audience happy for at least couple of years (since its working on 5.18 and should also work on 5.19). I think users of respective platforms open a bug there and document procedures there, and also discuss this on platform specific forums. Since vanilla kernel testing with vanilla linux may not be practical for general audience.
Tested the kernel patch (https://bugzilla.kernel.org/attachment.cgi?id=301473) on ubuntu mainline 5.19.11 kernel, locally compiled. mount -t cifs is working fine with "vers=1.0,sec=ntlm" mount options. files are accessible from old device. All other Linux Mint 21 features are working fine with this patched 5.19.11 kernel. Will test the patch tomorrow on 5.15 official ubuntu 22.04/Mint 21 LTS stable kernel sources. Following alternative FUSE GVFS (user space samba fs client) is also working in all kernels without any kernel patch on Linux Mint 21 (ubuntu 22.04) # Add following lines in /etc/samba/smb.conf file [global] section # Allow old client devices to connect to this machine's samba sever server min protocol = NT1 lm announce = yes lanman auth = yes ntlm auth = yes # Allow samba client tools to be able to connect to old servers/nas devices client min protocol = NT1 client ntlmv2 auth = no client use spnego = no client lanman auth = yes Then mount using mount.fuse or gio command: gio mount smb://user@server/share If you have Desktop UI, in Nautilous/Nemo/Thunar file manager location bar type: smb://user@server/share Enter workgroup/password if any. Check if its mounted: ls /run/user/$UID/gvfs/ 'smb-share:server=server,share=share,user=user' Now the share should also show in UI File browsers
(In reply to Ganesh Ingle from comment #43) > # Add following lines in /etc/samba/smb.conf file [global] section After adding lines you need to restart samba service: sudo systemctl restart smbd
(In reply to Jim from comment #41) > If security is a concern for this specific version of the protocol, why not > just require one more flag making the user acknowledge it isn't secure when > mounting or in fstab? Keeping known insecure code around that developers can't even test can be a burden and a risk. (In reply to Ganesh Ingle from comment #42) > Since kernel.org seems not to be willing to maintain this old code for > reasons of security, maintainer's burden and code complexity Well, Ronnies patch is trying to address the problem with a middle-ground; calling that "not to be willing" might be counter productive. (In reply to Ganesh Ingle from comment #43) > Tested the kernel patch > (https://bugzilla.kernel.org/attachment.cgi?id=301473) on ubuntu mainline > 5.19.11 kernel, locally compiled. > mount -t cifs is working fine with "vers=1.0,sec=ntlm" mount options. files > are accessible from old device. Thx for testing.
Created attachment 302979 [details] smb1_Linux_5.15.72_unpatched_failed.pcap
Created attachment 302981 [details] smb1_Linux_5.15.72_patched_succeeded.pcap
I was able to successfully test the patch from Ronnie Sahlberg from comment 23 (https://bugzilla.kernel.org/show_bug.cgi?id=215375#c23) against the vanilla stable Linux kernel 5.15.72. As I'm new to kernel compiling, I present below my steps, so that hopefully you can confirm that this was a valid test. Also from just looking at Ronnie's patch it does the right thing, it adds back the missing 1 byte for the empty password which causes the regression problem for SMB1 with guest access (i.e. without password). I also uploaded a tcpdump trace from trying to access an SMB1 device in guest mode (no user/pass) from unpatched kernel 5.15.72, which fails due to the regression, and a tcpdump from the same access with the patched kernel, which succeeded just as it should. For those interested, in trace smb1_Linux_5.15.72_unpatched_failed.pcap, packet 12, byte 0x71 you can see the start of the UNC "\\10.1.1.9\IPC$", which is off by 1 byte, it should have started at byte 0x72. In trace smb1_Linux_5.15.72_patched_succeeded.pcap, again packet 12, the UNC correctly now starts at byte 0x72. For details on the missing 1 byte and how this leads to strange characters in the SMB server log and a failed connection, see comment 22 (https://bugzilla.kernel.org/show_bug.cgi?id=215375#c22). My procedure: - I started with Ubuntu 22.04.1 LTS, which uses its own Ubuntu kernel 5.15.0-50-generic - I compiled vanilla stable Linux kernel 5.15.72 - I then restarted my distro with that new unpatched vanilla kernel, which worked fine. - Now with the unpatched vanilla kernel 5.15.72 I reproduced the issue when trying to access my SMB1-server. - Then I applied Ronnie's patch. - I compiled again the now patched Linux kernel 5.15.72 - I then restarted my distro with that new patched kernel, which worked fine. - Now with the patched kernel 5.15.72 I verified that I could to access my SMB1-server and the fix solved the regression. In details: Started with Ubuntu 22.04.1 LTS lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 22.04.1 LTS Release: 22.04 Codename: jammy uname -a Linux ubuntu22 5.15.0-50-generic #56-Ubuntu SMP Tue Sep 20 13:23:26 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux Compiling vanilla stable 5.15.72 mkdir -p linux cd linux wget https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.15.72.tar.xz tar xf linux-5.15.72.tar.xz rm linux-5.15.72.tar.xz cd linux-5.15.72/ cp /boot/config-5.15.0-50-generic .config sed -i 's:CONFIG_SYSTEM_TRUSTED_KEYS="debian/canonical-certs.pem":CONFIG_SYSTEM_TRUSTED_KEYS="":' .config sed -i 's:CONFIG_SYSTEM_REVOCATION_KEYS="debian/canonical-revoked-certs.pem":CONFIG_SYSTEM_REVOCATION_KEYS="":' .config make -j7 (answer NO to all questions, e.g. to ASHMEM, ANDROID_BINDER_IPC, ANDROID_BINDERFS) sudo make modules_install sudo make install sudo reboot now ----- Trying now with unpatched vanilla kernel: uname -a Linux ubuntu22 5.15.72 #2 SMP Tue Oct 11 16:58:48 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux sudo mount -t cifs //10.1.1.9/Harddisk /mnt --verbose -o vers=1.0,guest,ro mount.cifs kernel mount options: ip=10.1.1.9,unc=\\10.1.1.9\Harddisk,vers=1.0,user=,pass=******** Retrying with upper case share name mount.cifs kernel mount options: ip=10.1.1.9,unc=\\10.1.1.9\HARDDISK,vers=1.0,gid=0,user=,pass=******** 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) Mounting failed, on SMB server see see the "chinese" characters. ----- Then applied the source code change of Ronnie (https://bugzilla.kernel.org/show_bug.cgi?id=215375#c23) Line numbers are different as base is 5.15.72 kernel, but content change is the same. diff a/fs/cifs/connect.c b/fs/cifs/connect.c 3714,3719c3714,3717 < if (tcon->pipe || (ses->server->sec_mode & SECMODE_USER)) { < pSMB->PasswordLength = cpu_to_le16(1); /* minimum */ < *bcc_ptr = 0; /* password is null byte */ < bcc_ptr++; /* skip password */ < /* already aligned so no need to do it below */ < } --- > pSMB->PasswordLength = cpu_to_le16(1); /* minimum */ > *bcc_ptr = 0; /* password is null byte */ > bcc_ptr++; /* skip password */ > /* already aligned so no need to do it below */ And compiled again: make -j7 sudo make modules_install sudo make install sudo reboot now ----- Trying now with patched vanilla kernel: uname -a Linux ubuntu22 5.15.72 #2 SMP Tue Oct 11 16:58:48 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux (new timestamp, this is the patched kernel) sudo mount -t cifs //10.1.1.9/Harddisk /mnt --verbose -o vers=1.0,guest,ro mount.cifs kernel mount options: ip=10.1.1.9,unc=\\10.1.1.9\Harddisk,vers=1.0,user=,pass=******** Mounting works and the SMB mount is accessible again as it should.
Thanks for testing and verifying the patch in comment #23
Patch posted to linux-cifs: https://marc.info/?l=linux-cifs&m=166552970703349&w=2
Thanks Ronnie for forwarding the patch!
Carsten, thank you for the detailed guide. Three hints: 1. Make sure disable to build debug symbols. $ scripts/config -e DEBUG_INFO_NONE $ scripts/config -s DEBUG_INFO_NONE y 2. `make olddefconfig` should set all unknown configuration values to the default chosen by the developers. 3. To build a DEB package use `make bindeb-pkg -j7`.
(In reply to Ronnie Sahlberg from comment #51) > Patch posted to linux-cifs: > https://marc.info/?l=linux-cifs&m=166552970703349&w=2 (lore.kernel.org URL [1]) Thank you for posting the patch. Should *BugLink* instead of *BZ:* be used, cf `scripts/checkpatch.pl`. @all, the maintainers asked for help on setting up test VMs [2]. [1]: https://lore.kernel.org/linux-cifs/20221011231207.1458541-1-lsahlber@redhat.com/T/#u [2]: https://lore.kernel.org/lkml/CAH2r5mvQnQTDQaci-NbLBjRb=gCPtMewrKhLBOLGrN2_Zpc3Bg@mail.gmail.com/
(In reply to Paul Menzel from comment #54) > > Thank you for posting the patch. That one looks WIP anyway, as without a commit message I'm pretty sure it won't make it far (and Ronnie is likely aware of this). :-D > Should *BugLink* instead of *BZ:* be used, No no no! See this msg from Linus: https://lore.kernel.org/all/CAHk-=wgs38ZrfPvy=nOwVkVzjpM3VFU1zobP37Fwd_h9iAD5JQ@mail.gmail.com/ To quote: ``` please stop making up random tags that make no sense. Just use "Link:" ``` > cf `scripts/checkpatch.pl` Ohh, interesting, I'd say that shouldn't be there.
Thanks to Paul for the hints for the next time... I'm willing to set up a VM for testing, but wonder what that VM should be like and asked that question back in the email thread at https://lore.kernel.org/lkml/0259a530-32af-f6be-b2e5-fcfbda80a052@gmx.de/
Fix was merged to mainline and thus will be in 6.1-rc1, which should be out later today: https://git.kernel.org/torvalds/c/2f6f19c7aaad5005dc75298a413eb0243c5d312d Thx to Ronnie for the patch and all those that tested it, that really helped in this tricky situation. If more people had done this this could have been solved earlier. Backporting to stable/longterm tree is not scheduled yet, but might happen soon anyway. If nothing happened in 3 weeks, tell me. Hopefully there are no CIFS 1.0 devices of significance left that still don't work after that change, but worked with 5.14 and earlier. If you think there are, maybe open another bug (CC me and mention it here) so we can collect how many there are and if a workaround for those can be found, too.
I tested 5.18.8 patch ( https://bugzilla.kernel.org/attachment.cgi?id=301473 ) on 6.0.1 ubuntu mainline kernel. It is also working fine along with other OS functionality. I had to install gcc 12 for kernel to compile. Didn't get chance to test 5.15.x patch on 5.15.x series, apparently it is slightly different than 5.18.8 patch. A related but different issue, I had trouble copying files larger than 500mb, all copy programs I tried would give "error slicing file", and abort copying last portion of file. The issue exists for a long time (since 5.4 kernel) for smb1 shares. Apparently there is a meta-data mismatch when a program saves/syncs a file and reloads meta-data, sees it as external modification and stops copying. I have the share working for now with following mount.cifs options: sudo mount //tc.local/apdata /mnt/tc/apdata -t cifs -o "cred=/home/ganesh/.apcred,domain=WORKGROUP,ip=10.0.1.1,servern=tc,rw,uid=1000,gid=1000,vers=1.0,sec=ntlm,noposix,cache=strict,rwpidforward,noserverino,nosetuids,actimeo=5" actimeo=5 option reduces meta-data reload interval from default 1 second to 5 seconds. Other options try to reduce the diffences seen in meta-data. Copy programs are working for now, I need to do some more rsync based testing to make sure files are indeed copied in full. SMB1 shares used to work reliably in the past, but support is gradually being faded because devolopers may not have old devices around to test. On a related note, SMB1 is anyway slow/ineficient by design, it is better we upgrade the devices, move around hard drives to better NAS servers. I am also taking out hard drive from time capsule device, because the copy over smb is no longer reliable, your files may be left in a corrupt state.
@Ganesh, thank you for the feedback. Please create a new issue for the new issue.
I installed the 6.1 rc4 kernel which as far as I can tell includes this fix. But this is still not working to connect to my apple time capsule. > sudo mount.cifs //capsuleIPAddress/Data /media/thecapsule/ --verbose -o > vers=1.0,sec=ntlm,user=,pass=****** Output: mount.cifs kernel mount options: ip=192.168.86.91,unc=\\192.168.86.91\Data,vers=1.0,sec=ntlm,user=root,pass=******** mount error(22): Invalid argument Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg) So I run > sudo dmesg output: [ 175.318151] Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers [ 175.318162] CIFS: VFS: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers [ 175.318166] bad security option: ntlm [ 175.318168] CIFS: VFS: bad security option: ntlm Double checking my kernel: > uname -mrs output: Linux 6.1.0-060100rc4-generic x86_64 Any ideas? Thanks!
(In reply to captainr0bbo from comment #60) > I installed the 6.1 rc4 kernel which as far as I can tell includes this fix. Please open a new bug and afterwards mentioned the bug id here; continuing the discussion here is just confusing.
ah ok, sorry about that. New bug 216682
(In reply to captainr0bbo from comment #60) > I installed the 6.1 rc4 kernel which as far as I can tell includes this fix. > > But this is still not working to connect to my apple time capsule. > > > sudo mount.cifs //capsuleIPAddress/Data /media/thecapsule/ --verbose -o > > vers=1.0,sec=ntlm,user=,pass=****** > By default Kconfig (compile time) option to enable weaker NTLM/LANMAN authentication is turned off. You need to enable that option when configuring your kernel before compilation. If you obtained binary kernel from some maintainer (e.g Ubuntu mainline ppa), then you need to request them to enable it in their build system. Apple TC (4th gen) can allow SMB guest account (R/W), you need to configure it so. You need to use "sec=none" mount.cifs option in that case.
(In reply to Ganesh Ingle from comment #58) > A related but different issue, I had trouble copying files larger than > 500mb, all copy programs I tried would give "error slicing file", and abort > copying last portion of file. Turned out the hard drive inside time capsule was actually failing due to old age. Linux Disks utility's SMART report shows more than 1250 bad blocks, growing with more writes. So it is not a linux kernel issue. Tried time capsule's attached USB thumb drive share, SMB1 read/write is working fine with NTLM patch and my locally compiled 6.0.1 kernel (sources obtained from Ubuntu mainline ppa maintainers site as mentioned before).
Reminder: continuing the discussion here is likely more confusing then helpful. That being said: If you have devices that (1) still don't work with the guest mode SMB1 support that is now in mainline kernel and the latest 6.0.y and 5.15.y versions and (2) would not be considered "museum style hardware" at this point, please mentioned them in Bug 216682 (if possible please state when they were manufactured/last sold and when they got their last firmware update)
Hello, I run OpenSuse Leap 15.4 with kernel 5.14.21 and I have the same issues, I guess, after the last update of cifs-utils. I used to mount a share of a Lacie Cloudbox in order to backup my files with rsync and it is not possible anymore. I can access the share on the NAS via smb but it is impossible to mount. I understand the safety issues discussed above but firmware updates for this device seem to have come to an end but it is still working fine and for me it is funny to consider it "museum style hardware"
Reminder (again): continuing the discussion here is likely more confusing then helpful. (that's why I now will remove myself from the list of CCed people) (In reply to Matteo Bagnoli from comment #66) > it is funny to consider it "museum style hardware" Well, then you maybe should have done what Comment 65 suggested. But sadly in the end it likely won't make a difference, as I brought the issue to Linus attention again recently, but got not reply. See Bug 216682 Comment 14 for details.