smb issues past 8.0.2

1st Official Post

    I'm new to the forum, but have been using LibreElec and Kodi for a year or two and love it. I have LibreElec on two different Pi3 boxes, and also run Kodi as an Android app on two tablets. I use those four devices to access my audio and video files that are housed on a USB drive attached to my Asus RT-AC56U router as an NAS via an SMB share. The tablets are running Kodi 17.5 and work perfectly with this setup. The two Pi3 boxes running LibreElec can not connect to the share if I update past LibreElec 8.0.2/Kodi 17.3. When 17.4 came out a while ago and I saw that the tablets had updated to it, I upated to the two Pi boxes manually and went through hell; they would NOT connect to the share. Messages appeared telling me the media files were missing and asking if I wanted to remove them from the library. I tried everything; removing and adding back the smb share path, passwords, and anything I could think of, but nothing worked. Restoring previous backups only rolled back my library to earlier states, so I manually installed an older version of LibreElec and Kodi 17.3, and got my functionality back. At the time, I read a bunch of posts and blogs about smb difficulties in that build of Kodi/LibreElec, so I figured I'd just wait until the next release. Well, 8.2/17.5 is here, and I just went through the same headache, ending with a reinstall of 8.0.2/17.3. I tried the different smb client settings in this new version of Kodi, but none of them worked (1.0, 2.0, 3.0, "none"). I can "browse" to the share, but it won't connect and won't accept my password. I know the password is right because I checked it on the tablets which work fine. AND.. it's the same password, username, and path I use when rolled back to 8.0.2/17.3.

    Any ideas what's causing this, and why my tablets don't have any trouble seeing the smb share using Kodi 17.4 and now 17.5?

    Thanks in advance for any help. This is driving me crazy..

    I had the same problems.

    And for me it was solved by enabling "Wait for network before Kodi startup" in the "Libreelec" -> "Network" section.

    (don't remember the exact wording)

    Hope that helps

    Thanks for the reply. Since posting but before seeing your reply, I've downloaded and installed OSMC's most recent OS for the Pi3, which comes packed w/ Kodi 17.4. Same exact issue there, so it must not be a LibreElec thing, but rather a Kodi/Pi issue. Running the update to 17.5 now to see what will happen. If (OK, when) that doesn't work, I'll give your idea a try.

    Edit: I tried the "wait for network" setting in OSMC's version... no dice.

    Edited once, last by MuseChaser (October 30, 2017 at 5:10 PM).

    An update... Using information gleaned from the official Kodi community forums, the issue seems to be between the smb implementation of some Asus routers w/ attached usb drives and Pi's running Kodi. Great. In any case, I found the fix, but it entailed ssh'ing into Libreelec and adding a user .conf file.

    The entire thread can be found here..

    Can Not Access SMB Shares after 17.4 Update

    Here's an excerpt from one of the posts..

    Milhouse Wrote: The strange thing is that the properties which need to be added in order to make the current smb.conf work with these Asus routers, ie.:

    Code:
    client use spnego = no
    client ntlmv2 auth = no

    were never included in previous versions of Kodi, so I'm not sure how or why they are needed now.

    The only possibly contentious property that has been removed (ie. disabled) is "client lanman auth" but this is for working with absolutely ancient Win95-era Samba servers (even my FreeNAS 8.3 server with Samba 3.6 will work without lanman).

    We were patching Kodi's creation of smb.conf to include these two lines. We noticed this became a necessity at some point
    in January for some networks; presumably because of Samba security changes in Debian.

    We probably need to re-add this patch.

    Quote from MuseChaser

    We probably need to re-add this patch.

    Nope - it was OSMC that included those options as as distro specific patch. LibreELEC has never included these options, and will not be including them in the future as while they may help your devices to interoperate they also weaken your overall network security. If you want/need to add them, you do so at your own risk.

    I would strongly advise that you demand a firmware update from your hardware vendor rather than continue to use an outdated and insecure Samba server in your router which puts your entire network at risk. As more major clients (ie. Windows etc.) drop support for SMB1 and insecure authentication you will find that your Samba server becomes less and less useful to you, and will ultimately just remain a gateway for exploitation.

    If you are unable to obtain an update for this insecure Samba server then my advice would be to disable it completely and find a more secure solution for file sharing - as an example, LibreELEC includes a secure Samba server.

    Quote from milhouse

    Nope - it was OSMC that included those options as as distro specific patch. LibreELEC has never included these options, and will not be including them in the future as while they may help your devices to interoperate they also weaken your overall network security. If you want/need to add them, you do so at your own risk.

    I would strongly advise that you demand a firmware update from your hardware vendor rather than continue to use an outdated and insecure Samba server in your router which puts your entire network at risk. As more major clients (ie. Windows etc.) drop support for SMB1 and insecure authentication you will find that your Samba server becomes less and less useful to you, and will ultimately just remain a gateway for exploitation.

    If you are unable to obtain an update for this insecure Samba server then my advice would be to disable it completely and find a more secure solution for file sharing - as an example, LibreELEC includes a secure Samba server.

    Thanks for the reply. The quote you attributed to me was actually from a developer on another website that I had quoted. In any case, some followup questions if you don't mind..

    1. I've combed the internet and the menu structures of my router, and can't find any information regarding the smb protocol used by my Asus RT-AC56u router. It is running the most current stock firmware. Do you know for sure what it uses?

    2. I used Putty to add the two lines of code listed in my previous post in a newly-created smb.conf file using nano. This file was placed on the Raspberry Pi/Kodi box in question, and not on my router. How is this risking network security? There's nothing on the Kodi natively, and the only thing the Kodi can access are the media files on the HDD attached to my router. I'm not being snarky.. it's an honest question.

    I'm all for security, and I confess I don't really understand what those two lines of code did. I've read virtually all of the posts here and on the kodi site about the smb problems when upgrading from 8.0.2 to 8.2, but the only thing that worked for me was adding that code. It didn't ask me for passwords when accessing the media files which was strange, since the shares are configured at the router/hdd to require passwords. Also, I can't find the smb.conf file I created on the Kodi/Pi by browsing using a networked Win7 file manager, although I can see folders and files. Where is it?

    I know... lots of questions. I know enough about this stuff to function, but I'm not a hobbyist or professional code writer. If anyone can help out, I'd appreciate it. Step by step procedural instructions are GREATLY appreciated. Hey, I finally understand the words ssh, nano, putty, and a few others... I'm getting better! :)

    Thanks again.

    • Official Post

    1.) No, we have no clue what proprietary shitty SMB code runs in an ASUS router for their "share disk" feature (or whatever it is).

    2.) SMB1 is considered a security risk. By forcing Kodi to continue using SMB1 you are still at risk. Disabling NTLMv2 auth over SMB1 (which is what those two lined do) degrades the already crap security level to something worse than plain normal SMB1. At the end of the day you are at no greater risk than you were six months ago. The only change is you (and many other users) are now marginally less ignorant of that risk, even if you don't understand it.

    3.) The active SMB conf is documented clearly in the release notes that nobody bothers to read.

    I read them, I just have no clue what the hell it all means. I just know that what used to work doesn't anymore, which is most unfortunate for those of us that don't know how to fix it. In the end, I guess some of us will have to move to other platforms if need be. Unfortunately.

    MuseChaser:

    1. I've no idea what server the ASUS uses, all I know is that for it to work with a secure client much of the security in the client needs to be disabled which suggests a) ASUS is using a really old and insecure implementation of Samba server (if it even is Samba) and/or b) the ASUS server has been configured with a bias to support obsolete insecure clients from the turn of the century (Windows 98 etc.).

    You really should contact ASUS and ask them to get their sh1t together as the world has woken up to the insecurity of SMB and is doing something about it, so why aren't they?

    2) It risks security because SMB1 when enabled on the client (which is what negotiates the initial connection) puts the client at risk of man-in-the-middle attacks. Sure, the risk for you is low, but that may not be the case for everyone who may not appreciate all of the data on their network being encrypted and held to ransom because they continued to use SMB1 on a media centre.

    Quote from Superlink

    I guess some of us will have to move to other platforms if need be. Unfortunately.

    Pretty much every platform (apart from ASUS?) is heading in the "more secure SMB" direction, led mainly by Microsoft who have been saying for years that users should stop using SMB1, and in fact SMB1 (and anonymous account access) is now disabled by default on all current Microsoft operating systems.

    So this change is just something you'll need to accept, that using SMB now requires you to do sane things like setup a sharing user account on Windows, and stop using SMB1 on clients as it is a vector for exploitation (and most servers will no longer support it in future, anyway). If you really must continue using SMB1 because of an outfit like ASUS that doesn't take your security seriously then at least you will do so knowing all of the risks.

    Complaining to us really is not the solution - talk to ASUS and demand a firmware update with a modern and secure Samba server.

    Hi, I've got the Asus DSL-ac68u, with 3.0.0.4.380_7712 Firmware, just ssh'd into my router and it shows it's using samba 3.0.33, no wonder we have a bad time with samba on this one.

    If you wanna check yours, enable ssh in your asus router, use something like bitvise ssh login to router with admin credentials and enter smbd -V at comand line and it'll show your version.

    Samba 3.0.33 released 27 Nov 2008, and it has no support for SMB2 or better. It will also be riddled with security bugs that are being actively exploited by current malware. ASUS need to get a serious grip if they're still shipping this turd in current products, there really is no excuse for it.

    Assuming an update isn't available with a modern Samba server your best bet would be to disable the ASUS Samba server _completely_ so that it no longer starts, and use something else that is more secure.

    Quote from Superlink

    I read them, I just have no clue what the hell it all means. I just know that what used to work doesn't anymore, which is most unfortunate for those of us that don't know how to fix it. In the end, I guess some of us will have to move to other platforms if need be. Unfortunately.

    I felt exactly the same as you. You have to ask for help, be patient, ask again if you don't understand and eventually you will overcome the problem. In the case of SMB shares, it was Microsoft that killed the anonymous and browse features when accessing shares. This was necessary for security though. If your hardware doesn't support the new SMB versions, you will have to bite the bullet and replace it or stay with older versions of Libreelec. As far as moving to another platform - good luck with that. They most likely will have the same issues.

    Quote from blueribb

    I felt exactly the same as you. You have to ask for help, be patient, ask again if you don't understand and eventually you will overcome the problem. In the case of SMB shares, it was Microsoft that killed the anonymous and browse features when accessing shares. This was necessary for security though. If your hardware doesn't support the new SMB versions, you will have to bite the bullet and replace it or stay with older versions of Libreelec. As far as moving to another platform - good luck with that. They most likely will have the same issues.

    Going to stay with 8.0.2 for now. When I have no choice but to update, I will try Merlin's firmware for my router if a new one hasn't been releaed by then. As far as other platforms go, android is still good to go.

    I'm sorry to revive this old thread, but I'd like learn a bit more about this issue. After updating one of my Pi3 boxes to LibreElec 8.2.3 (and the firmware on my Asus RT-AC56u to 3.0.0.4.382_50010, hoping it would help with whatever SMB issues I've been having since kodi 17.3), I hit the usual problem with endless password/login loops when trying to access my smb shares on the usb HD attached to my router. The smb share showed up fine and I could browse to it, but it wouldn't accept my login information for access. As before, I had to "solve" the problem by creating /storage/.kodi/.smb/user.conf with the two lines of code referenced earlier in this thread; changing the SMB1/SMB2/SMB3 settings via the GUI accomplished nothing.

    After adding the spnego and ntlmv2 lines, everything works fine, except it no longer asks for my password and connects without it.. ?!? How is that possible since I have the share password protected at the router? How does code on a client box bypass a request from a server for a password?

    Thanks to the instructions from Yogensha a few posts back, I've checked and verified that this new firmware from Asus is still using Samba 3.0.33.

    Kodi 17.6 running on my Android tablet has no issues at all connecting to the server, and it does require and accept my login credentials. Why is that, in light of the fact that Kodi 17.6 via Libreelec on a Pi3 (actually, I have it on two of them, and am about to update the second one from 17.3 to 17.6....) won't without those two lines of code. Is the issue within Kodi, or is it within the differences in the Android and Libreelec OS?

    From a security standpoint on the Pi3 boxes, am I better off with 17.3, which at least requires and accepts my login credentials for share access, or 17.6 and those two lines of code? Even better, is there a way to patch Samba 3.0.33 up to 4.7.5? If there is, is it doable by someone who shares some of superlink's and blueribb's (past) frustrations? I'm learning as I go and enjoy it, but don't know enough to fully understand all of the stuff I'm reading in the blogs and forums. Made a couple leaps forward today, and am getting more comfortable with basic SSH commands, directory navigation, and nano. Haven't done much at that level since the old DOS/pre-windows days. Back then, I kind of knew what I was doing.

    Speaking of SSH.. I can't figure out how to change the default root/libreelec user/password combo, and I KNOW I should. Googling was NOT my friend on that, and I'm shocked.

    Anyway, thanks for any help and specifics anyone is willing to share. I'm strongly considering switching over to Merlin for the router as most have suggested, but the process intimidates me.. reconfiguring the whole network again, all the mac filters, static IPs for 15 devices, possibility of bricking my router.. shudder...

    Best to all...

    With Kodi 17.6/LE 8.2.3 there's no longer any need to add lines to user.conf - simply set "Maximum protocol" to SMB1 and enable "Use legacy security", and this should get Kodi working with your Asus router. With LE 8.2.3 you should remove the workarounds from user.conf and just let Kodi manage it.

    I can't really say why the Asus Samba server doesn't require a password - that's a server configuration issue so you should contact Asus.

    You should also contact Asus about fixing their decade-old insecure version of Samba - apparently Samba 4 requires more space (ie. NAND flash) which makes upgrading to Samba 4 more difficult, but this doesn't really excuse Asus continuing to ship Samba 3 on new hardware where they could have increased NAND storage.

    You'll also be glad to know that Samba will be announcing important security updates tomorrow, which we will incorporate into future LE8 releases. Needless to say, your Asus router won't have these updates and will remain exposed.

    My advice would be to disable Samba 3 entirely in the Asus router and use an alternative, modern and more secure server - you could even use LibreELEC on an RPi. Asus are either too cheap, or don't care about end-user security, or both. Now that all distros are dropping SMB1 support (including and in particular Microsoft) it will be interesting to see if Asus change course.

    Changing the default root password is not supported in LE8 but is supported in LE9 (due in about 2-3 months).

    Milhouse,

    Thanks a bunch for your reply. I deleted my user.conf file, and then followed your suggestion which worked; after selecting SMBv1 as maximum protocol under Services, "Use legacy security" was no longer greyed out and was now available.

    I have also contacted Asus via their chat support, got an "inquiry number," and asked them pointed questions about why they're still using Samba 3.0.33 from Nov 2008, and when we can expect something a bit more recent and secure. The chat rep was not.. umm.. real informed. He made ME seem like I know what I'm doing...

    They're supposed to get back to me w/in 48 business hours. I'm not holding my breath.

    In any case, thanks for the help and the prod to hassle Asus. Anyone else reading this thread, please contact Asus, too.

    Hello, I plan use raspberry pi 3 (libreelec 8.2.3) as player to tv and server for two usb hdd.

    Raspberry pi as server and two pc and 1 TV with Minix neo x8h plus as clients.

    Share with pcs work fine. But With minix is problem, instaled kody support only smb v1 protocol and inpossible update to 17.4+

    Libreelec not support NFS server.

    So is safty allow On raspberry pi smb v1?

    THX