Referencing bug 215375. 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!
The fix in https://bugzilla.kernel.org/show_bug.cgi?id=215375 works if the SMB1 server works in guest sharing mode, i.e. does not require a user/pass to log in. Thus, a mount similar to 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 should work (assuming your SMB1 server works in guest sharing mode, which it tells the client via the SMB protocol). If the server was a samba 3.x server, then the following Samba config would trigger the regression issue 215375 on a kernel 5.15 and it should be fixed with kernel 6.1. # /etc/samba/smb.conf [global] # This is the most important configuration. Only in "security=share" mode the regression described in https://bugzilla.kernel.org/show_bug.cgi?id=215375 is reliably triggered. security = share guest account = root [public] path = / guest ok = yes only guest = yes writable = no
Hm. Apple Time Capsule does require a password. in bug 215375, Genesh seemed to have success with this patch, using option sec=ntlm. Why am I getting "CIFS: VFS: bad security option: ntlm"?
Sorry I am realizing that little patch did not fully reverse this commit: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=76a3c92ec9e0668e4cd0e9ff1782eb68f61a179c This comment confused me, I thought the patch everyone was referring to was included in this fix. But it is not. https://bugzilla.kernel.org/show_bug.cgi?id=215375#c57 So is the conclusion that NTLM is not coming back? We must either patch ourselves or use an older kernel. Thanks!
(In reply to captainr0bbo from comment #3) > > So is the conclusion that NTLM is not coming back? Well, kinda. See Linus comment on this here: https://lore.kernel.org/all/CAHk-=wjSBvRk-ksUBOiQzJd=e19UZKvOSZs1UHahK5U0QVh6RQ@mail.gmail.com/ Due to the security impact it will be hard to convince people to re-add NTLM, but if there are very strong reasons to it might be worth a shot. Which leads to the questions * how old and common is the particular apple time capsule? * are other operating systems that lack NTLM support (or where it's disabled) able to mount it somehow? IOW: maybe there is another way to access them that doesn't require "a 20+ year old legacy and insecure protocol that nobody should be using"
* how old and common is the particular apple time capsule? Apple discontinued selling the time capsule in June 2013 and released the last firmware update for it on 5/30/2019. I am unsure how common it is or how many were sold. * are other operating systems that lack NTLM support (or where it's disabled) able to mount it somehow? IOW: maybe there is another way to access them that doesn't require "a 20+ year old legacy and insecure protocol that nobody should be using" MacOS is able to connect to it using AFP and SMB. Windows 10/11 allows you to re-enable SMB1 in the control panel and connect to it. I certainly don't want to waste anyone's time, but 2 other modern OSs still support it.
(In reply to captainr0bbo from comment #5) > * how old and common is the particular apple time capsule? > > Apple discontinued selling the time capsule in June 2013 and released the > last firmware update for it on 5/30/2019. > I am unsure how common it is or how many were sold. Thx, that's good to know. > * are other operating systems that lack NTLM support (or where it's > disabled) able to mount it somehow? IOW: maybe there is another way to > access them that doesn't require "a 20+ year old legacy and insecure > protocol that nobody should be using" > > MacOS is able to connect to it using AFP and SMB. > Windows 10/11 allows you to re-enable SMB1 in the control panel and connect > to it. That only partially answers the question that afaics would be helpful to have answers: do MacOS and Windows really need NTLM support for that, or are they able to access the devices somehow without it? > I certainly don't want to waste anyone's time, but 2 other modern OSs still > support it. Well, in the end we need to convince the maintainers and/or Linus that re-adding code for a obsolete and known insecure protocol is a good idea. That won't be easy and likely needs a developer to driver it: https://lore.kernel.org/all/CAHk-=wjSBvRk-ksUBOiQzJd=e19UZKvOSZs1UHahK5U0QVh6RQ@mail.gmail.com/
(In reply to The Linux kernel's regression tracker (Thorsten Leemhuis) from comment #6) > That only partially answers the question that afaics would be helpful to > have answers: do MacOS and Windows really need NTLM support for that, or are > they able to access the devices somehow without it? MacOS can access via AFP. But Windows does not support AFP, thus SMB1 with NTLM is the only other option to access the network drive. I am not a kernel developer and cannot really advocate for this being mainstream supported. When I opened this bug, I thought it was supposed to have been fixed as I mentioned earlier - my misunderstanding of 215375. So if this should be closed, please feel free to do so. Thank you for your responses!
I am not sure what exactly was patched to mainline 6.1 as part of bug 215375. I tried patch ( https://bugzilla.kernel.org/attachment.cgi?id=301473 ) on 6.0.1 kernel sources and I can confirm it works with Apple TC 4th gen with mount.cifs options "vers=1.0,sec=ntlm,user=u,password=p" or "vers=1.0,sec=none". In my patched kernel sources, by default Kconfig (compile time) option to enable weaker NTLM/LANMAN authentication is turned off. I needed to enable that option when configuring the kernel before local 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 (mine 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, no need to use user/pass. If you don't have Windows/MacOSX, you can still configure Apple TC using Airport Utility for Windows, running under Linux with Wine 7 from winehq ( https://wiki.winehq.org ).
We were asked to post here about "non museum" SMBv1 devices which still don't work with kernels 5.15.* (https://bugzilla.kernel.org/show_bug.cgi?id=215375#c65) My TP-Link Archer C1900 v1.0 router with a USB-attached "network disk" stopped working when NTLM was removed, afaict. Windows 10 can still access the drive if SMBv1 is enabled in the "Turn Windows Features On or Off" screen. I purchased this router, probably, in 2016 and no later firmware updates were releasted (the fw is 3.17.0 Build 20151009 Rel.61423n). --- $ uname -a Linux lxjima 5.15.0-53-generic #59-Ubuntu SMP Mon Oct 17 18:53:30 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux $ sudo mount.cifs //192.168.1.1/volume1 /m/nasdrive1 --verbose -o vers=1.0,ro,uid=0,forceuid,gid=0,forcegid,actimeo=60,guest,sec=none ...fails saying "No such device or address", but syslog says: [121132.604369] CIFS: VFS: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers [121132.604383] CIFS: Attempting to mount \\192.168.1.1\VOLUME1 [121132.611771] CIFS: VFS: \\192.168.1.1 failed to connect to IPC (rc=-6) [121132.612695] CIFS: VFS: cifs_mount failed w/return code = -6 And on Windows 10 I can browse \\192.168.1.1\volume1 successfully. Please direct me to docs or instructions if there is something else I need to do to regain access. Thanks.
> [121132.604383] CIFS: Attempting to mount \\192.168.1.1\VOLUME1 I copied the wrong syslog lines in comment 9, mistakenly showing the result of mount.cifs retrying with an upcased share name. The original attempt produced slightly different syslog (note the "...not rec'd unless required..."): [121132.595879] CIFS: VFS: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers [121132.595905] CIFS: Attempting to mount \\192.168.1.1\volume1 [121132.603388] CIFS: VFS: \\192.168.1.1 failed to connect to IPC (rc=-6) [121132.604291] CIFS: VFS: cifs_mount failed w/return code = -6 [121132.604364] Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers
I have an Epson printer/scanner (model WF-4630) which exposes scanned documents via an SMB share. The share has no security, but requires an arbitrary non-empty username and password to connect. Any username/password combo works, as long as they are not blank. Obviously, we access it over a secure wired LAN. I have tried various cifs mount options, and it seems that the only combination the printer accepts is: "vers=1.0,sec=ntlm". I'm dismayed to discover that this no longer works with a 6.0 series kernel. I should note that the printer has been updated to the the latest vendor firmware. Ironically my partner, who runs Windows 10, can still access the printer. I believe this bug should be marked as a regression.
(In reply to Ken Milmore from comment #11) > I believe this bug should be marked as a regression. This won't make a difference, as it's known to be a regression. I tend to think it was the wrong decision to not fix this, but in the end it was made my Linus here: https://lore.kernel.org/all/CAHk-=wjSBvRk-ksUBOiQzJd=e19UZKvOSZs1UHahK5U0QVh6RQ@mail.gmail.com/ Everybody is free to convince him to revisit that decision, like I did in that thread months ago. But for now I'm not interested in doing that, as I'm pretty sure nothing will change unless somebody steps up to regularly test and maintain the code that is needed for this.
Apple Time Capsules still not working on 6.1.8 due to this regression.
For the record, I recently pointed Linus to this ticket, but there was no reaction: https://lore.kernel.org/all/62fb7c9a-179a-f3f0-93b6-5e74f88dad63@leemhuis.info/ I guess we are stuck here, unless * somebody else tries the same and has more luck * someone submits a patch to re-add support for NTLM and commits to regularly test latest mainline and maintain the code
Maybe it should be added here that the often mentioned Apple Time Capsule was officially available on the market until 2018. So this is in no way "stone age" hardware. It was unfortunately just designed by a somehow "narrow minded" company. Most likely SMB1 was selected over SMB2 because it performed much worse than Apple's own AFP. ;-) Whatever, Arch Linux users have the great alternative to use the AFP protocol instead of SMB1. Just install the "afpfs-ng" package and use the install/setup shellscript from here: https://www.youtube.com/watch?v=miHxtIqp94w Current afpfs-ng version (as of August 2023) is 0.8.2-3. https://archlinux.org/packages/extra/x86_64/afpfs-ng/ Note, this is unfortunately NOT possible on Debian/Ubuntu because the afpfs-ng package is missing in the repository. The main afpfs-ng project is in a dormant/abandoned stage, the Arch package is maintained "in-house" by Arch volunteers. I think if the kernel devs decide to simply scrap NTLMv1 support from the kernel then there should be offered an alternative for end-users. So if NTLMv1 cannot be re-implemented then someone should rebuild a afpfs-ng package also for Debian/Ubuntu users. This would be definitely a big win for all affected Apple products. :-D