[SOLVED] cannot connect to samba server after upgrade

amatriain · 2014-12-02 23:57:08

After upgrading samba and smbclient packages, I can no longer connect to a samba server. I've dropped and recreated the samba user with pdbedit to make sure it's not a problem with the user or password. I've also made sure that ports 445 and 139 are open in the firewall. I've checked with an android cifs client to make sure that the issue is with the server, not the client.

Trying to access a shared folder with Caja using gvfs opens a dialog asking for credentials. Entering the correct user/password/domain just makes the dialog appear again, instead of opening the folder.

"smbclient -L " correctly lists the shared folder, but when trying to mount it with "mount -t cifs" I get an error:

mount error(13): Permission denied
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

which if I'm not mistaken means that the credentials I passed have been rejected.

After downgrading both samba and smbclient packages back to 4.1.13-1 version, everything works again.

For the moment I've added samba and smbclient to my IgnorePkg array, but I'd like to know if this affects other people or if it's some quirk of my server.

Last edited by amatriain (2015-01-15 11:15:13)

hwkiller · 2014-12-05 02:13:56

I am having issues with the latest update too.
Could not connect to machine 127.0.0.1: NT_STATUS_LOGON_FAILURE

I get the NT_STATUS_LOGON_FAILURE no matter how I connect.
I have removed all samba users, re-added them, changed passwords, etc.

Even trying to change my own password via smbpasswd results in that error.
It worked fine on 4.1.13.

amatriain · 2014-12-05 09:14:47

Opened a bug report, please vote and comment there:

https://bugs.archlinux.org/task/43015

Nektarios · 2014-12-05 13:38:00

I have the same problem and encountered it today. I debugged it as much as I could but couldn't find any solution. I finally noticed that samba and smbclient where recently updated and I downgraded them to 4.1.13 and voila everything worked again. So I conclude that there is a bug with the 4.1.14 version. I also voted your bug report. Hope it will get fixed soon.

Last edited by Nektarios (2014-12-05 13:38:33)

TE · 2014-12-06 18:27:47

I have no dog in this fight, but in case y'all didn't know -- you can enable debugging to get more info. After the cifs module is loaded into the kernel it will create an interface /proc/fs/cifs/cifsFYI that you can echo 0-9 (0 = no debug, 9 = max):

echo 9 > /proc/fs/cifs/cifsFYI

You can then examine messages in your logging (journalctl, rsyslog, etc. - whatever you use) to help narrow in on what might be going wrong with it's attempt to mount he SMB share after the upgrade. Might find something useful... and you can also set it into a higher debugging mode in smb.conf which might also help. The upstream website has a whole HOWTO on it:

http://www.samba.org/samba/docs/using_samba/ch12.html

Between the two ends in debugging mode you should be able to suss out a better bug report.

prydom · 2014-12-07 09:10:47

I also spent some time attempting to debug this problem today. The only really useful information I found after scouring logs in "log level = 10" was the "NT_STATUS_NO_SUCH_USER" (the user exists as both a unix user and in the samba user database with the same password) error code. I can also confirm username mappings are functional; the failure path is different when a user actually does not exist. I also spent some time grepping an strace of the smbd process and got nothing useful out of that; the user database is read.

I am connecting to my samba server from a Windows 8.1 client so I do not have any useful debug information from there. I also reproduced the problem with smbclient on localhost and in a Debian VM though so the problem is not dependent on the client as previously noted.

I have rolled back to 4.1.13 for now as having Samba sharing is essential to my day-to-day activities.

trithemius · 2014-12-14 16:19:15

Downgrading didn't help - I went all the way back to 4.1.8. Adding "sec=ntlmv2" to the options got mine back up and running.

prydom · 2014-12-15 00:11:09

Spurred back on by some free time and trithemius' claim of getting things working again I decided to look more closely at my "log level = 10" logs by diffing it with the working log from a 4.1.13 instance.

I'll reiterate that my client is Windows 8.1 and so I am not mounting my shares with "mount -t cifs" or "smbclient" although my problem manifests there as well.

I have found some interesting differences between the auth process on 4.1.13 and 4.1.14 with no changes to the /etc/samba.conf file. I currently have a username map set incase the Samba account -> unix account mapping was broken but this problem manifests with or without it. These log snippets were taken with the forced mappings.

4.1.13 SAM account auth snippet (Good): https://gist.github.com/prydom/b18b7776e1e6f7cf2aac
4.1.14 SAM account auth snippet (Bad): https://gist.github.com/prydom/105e8a162e946e699e52

both versions smb.conf (testparam returns fine): https://gist.github.com/prydom/5953225edc9c5e7d1230

My next step is to do a code dive and figure out why "is_myname([SERVER'S NETBIOS NAME HERE])" returns 0 on 4.1.14 and 1 (as it's supposed to) on 4.1.13; I have a hunch that that causes the cascade of failures we see. check_samstrict_security seems to step in and kill the auth.

I have exams right now to study for though so it may take a while to get to.

EDIT: I lied, I did a dive into the diff file found here "http://samba.org/samba/ftp/patches/patc … 4.diffs.gz". They changed how the "smb_my_netbios_names" array is allocated in "samba-4.1.14/source3/lib/util_names.c" and must have broke "is_myname(cstring)". It's an upstream bug; I'll see if someone has reported this and if not report it.

Last edited by prydom (2014-12-15 00:34:36)

prydom · 2014-12-15 00:47:27

Sorry for the double post; if this is against the rules then could a mod please merge it. I figured this would warrant notifying anyone following the thread.

I have found a very simple workaround to the bug that at least some of us have reported: just shorten your NETBIOS name by adding "netbios name=[15 chars or less, simple ASCII chars only]" to your smb.conf.

I realized this when reading the comment added to the upstream code here:

--- samba-4.1.13/source3/lib/util_names.c	2013-06-13 11:21:02.000000000 +0200
+++ samba-4.1.14/source3/lib/util_names.c	2014-12-01 13:48:32.000000000 +0100
@@ -60,7 +60,15 @@
 {
 	SAFE_FREE(smb_my_netbios_names[i]);
 
-	smb_my_netbios_names[i] = SMB_STRDUP(name);
+	/*
+	 * Don't include space for terminating '\0' in strndup,
+	 * it is automatically added. This screws up if the name
+	 * is greater than MAX_NETBIOSNAME_LEN-1 in the unix
+	 * charset, but less than or equal to MAX_NETBIOSNAME_LEN-1
+	 * in the DOS charset, but this is so old we have to live
+	 * with that.
+	 */
+	smb_my_netbios_names[i] = SMB_STRNDUP(name, MAX_NETBIOSNAME_LEN-1);
 	if (!smb_my_netbios_names[i])
 		return False;
 	return strupper_m(smb_my_netbios_names[i]);

Hope this helps someone else. In light of this; it's probably not a bug at all but a regression due to spec.

EDIT: Reported upstream: https://bugzilla.samba.org/show_bug.cgi?id=11008

Last edited by prydom (2014-12-15 01:34:24)

DJ_L · 2014-12-15 04:25:17

Probably not helpful for this particular problem, but this is noted in the samba 4 AD wiki article regarding the netbios domain name (this has been true for a long time). Am I understanding correctly that this was a client problem? Should something be added about hostname length there too?

Thanks in advance.

-DJ

prydom · 2014-12-15 04:45:55

Just to confirm, my setup was a Arch file server (just fileserving, no Active Directory) and a Windows 8.1 client. I assume this also affects samba4 clients and possibly AD's but I don't use those features currently.

The problem I had was that previous to 4.1.14, the default behavior was to derive the NETBIOS name from the system's hostname without truncation. Later Windows clients and I assume Samba didn't care that the name chosen was > 15 characters but originally there was (and still is) a hard 15 character limit.

See: https://bugzilla.samba.org/show_bug.cgi?id=10896 and https://bugzilla.samba.org/show_bug.cgi?id=10920 for related changes within the last two months. My hunch is that the interaction between these two patches is what is causing this bug. I am not familiar enough with the codebase and the SMB protocol to confirm that though.

In the latest version of Samba there was a patch that changed the handling of NETBIOS names in such a way that caused server-side authentication to always fail no matter what the input if the server's NETBIOS name was greater than 15 chars or otherwise invalid.

Currently testparm does not complain if the user does not set their NETBIOS name (and their hostname is over 15 chars) and/or sets their NETBIOS name to an invalid name. It would probably be a good idea to mention this limitation on the Samba wiki page but hopefully Samba fixes this regression and NETBIOS names are properly truncated as before.

DJ_L · 2014-12-15 08:06:35

Thanks for the quick reply, the links, and the upstream report! I think I've just always followed the < 15 char rule without thinking about it (I tend to use very generic names like CN-DC-01, CN-PC-01, etc.). I'll add a note to the wiki article and add a commented line in the suggested smb.conf as a safety measure. Even if not affecting AD clients (which I'm still not certain that it doesn't), still need to support 3.x hardware devices.

amatriain · 2015-01-15 11:15:54

Setting a short netbios name in smb.conf is a viable workaround for me. Marking as solved.

jsnlry · 2015-01-15 13:21:11

I have a Seagate Blackarmor NAS and its shares are mounted as follows in /etc/fstab:

  //blackarmor/data  /media/blackarmor  cifs  user,username=xyz,password=verysecure,iocharset=utf8,uid=1000,gid=1000,file_mode=0644,dir_mode=0755  0  0

This worked for many years now, but yesterday I saw that I am no more able to mount this share. I get the following error:

  mount error(13): Permission denied
  Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

Is this related to the issue above? Or do I have another problem?

amatriain · 2015-01-15 13:25:20

@jsnlry: It may be the same issue. Try prydom's workaround described here: https://bugs.archlinux.org/task/43015#comment130771 . Worked for me. If it doesn't work for you, it may be a different issue.

jsnlry · 2015-01-15 13:33:31

But I can only change the configuration for my client. Here I already have a short name in smb.conf, but is this read if I only use cifs as client, not as client?
I don't know where to set the NETBIOS name in Blackarmor (web interface).

fluxboxer · 2015-03-06 02:16:16

jsnlry wrote:

But I can only change the configuration for my client. Here I already have a short name in smb.conf, but is this read if I only use cifs as client, not as client?
I don't know where to set the NETBIOS name in Blackarmor (web interface).

I've just had the exact same issue with an old WD MyBookWorld network drive. I could solve it by ssh-ing into it and install the newer version of samba by means of http://mybookworld.wikidot.com/first-steps-with-mbwe, not relevant for you though. My WD has just a minimal system with busybox and the above site offers an easy way to install and update software.

But your NAS may have , for instance, Debian as its server, so you may easily install and update packages. To be able to do that

1. Enable SSH in your NAS (hopefully it's possible through its web interface)

2. sudo pacman -S openssh

3. sudo ssh <your NAS' İP>

4. When asked for your NAS' root password enter it (you should see it in the web interface)

5. Now you should be able to update and install packages, by apt-get if it's Debian. Yet if it's an old version of Debian you might first need to upgrade Debian which might be a bit risky itself.

Somebody2night · 2015-03-28 20:11:15

I just come along this post, thanks for this!
i've upgraded my existing standalone SMB Server from Debian Wheezy (3.6.6) to Jessie (4.1.17) but then i noticed that no logon is possible anymore,
the message always was: check_ntlm_password: Authentication for user [xyz] -> [xyz] FAILED with error NT_STATUS_NO_SUCH_USER

The solution was to cut the length of the hostname to someting less then 8 chars.

Thanks for this!

uconnkoala · 2016-03-27 08:06:19

YES!!!!!!!

This just saved me days of debugging.

Thanks.

Arch Linux

#1 2014-12-02 23:57:08

[SOLVED] cannot connect to samba server after upgrade

#2 2014-12-05 02:13:56

Re: [SOLVED] cannot connect to samba server after upgrade

#3 2014-12-05 09:14:47

Re: [SOLVED] cannot connect to samba server after upgrade

#4 2014-12-05 13:38:00

Re: [SOLVED] cannot connect to samba server after upgrade

#5 2014-12-06 18:27:47

Re: [SOLVED] cannot connect to samba server after upgrade

#6 2014-12-07 09:10:47

Re: [SOLVED] cannot connect to samba server after upgrade

#7 2014-12-14 16:19:15

Re: [SOLVED] cannot connect to samba server after upgrade

#8 2014-12-15 00:11:09

Re: [SOLVED] cannot connect to samba server after upgrade

#9 2014-12-15 00:47:27

Re: [SOLVED] cannot connect to samba server after upgrade

#10 2014-12-15 04:25:17

Re: [SOLVED] cannot connect to samba server after upgrade

#11 2014-12-15 04:45:55

Re: [SOLVED] cannot connect to samba server after upgrade

#12 2014-12-15 08:06:35

Re: [SOLVED] cannot connect to samba server after upgrade

#13 2015-01-15 11:15:54

Re: [SOLVED] cannot connect to samba server after upgrade

#14 2015-01-15 13:21:11

Re: [SOLVED] cannot connect to samba server after upgrade

#15 2015-01-15 13:25:20

Re: [SOLVED] cannot connect to samba server after upgrade

#16 2015-01-15 13:33:31

Re: [SOLVED] cannot connect to samba server after upgrade

#17 2015-03-06 02:16:16

Re: [SOLVED] cannot connect to samba server after upgrade

#18 2015-03-28 20:11:15

Re: [SOLVED] cannot connect to samba server after upgrade

#19 2016-03-27 08:06:19

Re: [SOLVED] cannot connect to samba server after upgrade

Board footer