Since 4.3.7, Samba enforces a new security schema to avoid man in the middle vulnerabilities, so if your’re using a Guest user configuration or (a common case) your Linux Samba server is too old and don’t support NTLMv2 with SPNEGO even if you are using user/password, well, you need to disable the new security schema. A lot of Linux NAS lost they support a couple years after released, so, if you can’t ssh or gain an alternative acccess you will be hit by this problem.
So…What to do?
A combination of several configs already mentioned in this thread.
On both .smb/smb.confand /etc/samba/smb.conf, inmediatly after [Global] add:
client use spnego = no
client NTLMv2 auth = no
After that, sudo service smbd restart and that’s it, solved without the need of special mounts.
IMPORTANT: Any partial modification not including both configs on both smb.conf files, will fail.
A suggestion: This could be a security optional somewhere in the OSMC Config addon. Enabled by default could avoid many problems for newbies and wifes, but for security freaks, the option of cleaning both sentences must to be available. A simple checkbox firing the changes will do it.
This was tested over my 2 OSMC Raspberry Pis but also on my notebook with Ubuntu 16.04.
The problem was not solved entirely with the update you mention, that’s why I decided to contribute with my findings after the update
I own an old Popcorn Hour PCH-A110 which has Samba Server 3.0.9. I cannot upgrade Samba Server because I don’t have the toolchain to compile a new version. The may update didn’t solve the problem until I made the explicit disabling of SPNEGO.
From cc75c0b5aa8d4efa5ba5ed746785a1fab57dcb03 Mon Sep 17 00:00:00 2001
From: Sam Nazarko <email@samnazarko.co.uk>
Date: Thu, 21 Apr 2016 13:40:20 +0100
Subject: [PATCH] Fix connectivity to weaker shares
Signed-off-by: Sam Nazarko <email@samnazarko.co.uk>
---
xbmc/filesystem/SMBFile.cpp | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/xbmc/filesystem/SMBFile.cpp b/xbmc/filesystem/SMBFile.cpp
index 1f7af9b..4270e8c 100644
--- a/xbmc/filesystem/SMBFile.cpp
+++ b/xbmc/filesystem/SMBFile.cpp
@@ -121,6 +121,10 @@ void CSMB::Init()
fprintf(f, "\tsocket options = TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=65536 SO_SNDBUF=65536\n");
fprintf(f, "\tlock directory = %s/.smb/\n", home.c_str());
+ // post badlock fixes for legacy
+ fprintf(f, "\tclient use spnego = noclient\n");
+ fprintf(f, "\tntlmv2 auth = no\n");
+
// set wins server if there's one. name resolve order defaults to 'lmhosts host wins bcast'.
// if no WINS server has been specified the wins method will be ignored.
if (CSettings::GetInstance().GetString(CSettings::SETTING_SMB_WINSSERVER).length() > 0 && !StringUtils::EqualsNoCase(CSettings::GetInstance().GetString(CSettings::SETTING_SMB_WINSSERVER), "0.0.0.0") )
--
2.7.4
The above patch was included in the May update and should resolve the issue for you. Kodi’s use of libsmbclient only uses ~/.smb/smb.conf. If additional options are needed, then please let me know.
Edit: ah - maybe client ntlvm2 auth = no, not ntlmv2 auth = no
I was aware about Kodi idealistically using only de ~/.smb/smb.conf, but surprisingly even without a samba server installed the parameters are neeed in the /etc/samba/smb.conf too or old samba servers will fail to offer legacy auth. I don’t know why, maybe some other Kodi internal code is not clean enough about this and is using also the server config, even when a samba server is not locally present.
And yeah, definitively the “client” is needed before ntlmv2 auth. If you want, let me know when you correct the patch and I’ll clean my manual changes to test it, but I’m not so confident about an only samba client config modificaton. I’ve think that all Debian derivatives are in the same situation because I solved the problem in Kodi over Ubuntu in the same way with one difference over OSMC: No samba server config was installed on my Ubuntu 16.04 so, to get the /etc/samba/smb.conf present I had to install samba, samba-common, etc. Only after both configuration files were present and modified, Kodi over Ubuntu reached my legacy Samba NAS shares.
I can’t follow all of the above discussion but can confirm that the unmodified 2016-05-1 OSMC update does NOT fix the SMB share problem on a RPi2 with Windows10. I cannot connect with or without passwords.
OSMC 2016-04-01 on a similar RPi3 continues to share fine, RPi3 to Windows10.
martinrevert: Can you direct me to instructions on how to make the changes “spnego” and “NTLMv2” mentioned by you above. I can get to command line via PuTTY but am pretty well lost after that. Thanks.
I will test this as well when I get home. I updated last night and still couldn’t connect to my windows 10 machine. I’m on Vero1, but I’m guessing that doesn’t make any difference with this.
When I came home from dinner there was an update available, installed it, when it booted it had the same problem. Will try some other combinations of password/no password accounts but it looks like no go.
Puzzled that the release number is still 2016.5-01, I saw the patches prepare and go on?
I removed all my manual changes and reproduced the error. After that i applied the update and I can pass the auth of my problematic shares. So basically you were right, only .smb changes are needed in OSMC and /etc/samba/smb.confcan remain untouched. I don’t know why I had the sensation that it failed when I tested just that config manually. Nevermind, it’s solved.
Will try some other combinations of password/no password accounts but it looks like no go.