FS#48987 - [smbclient] Unable to connect to a samba share with a file browser with 4.4.2-1

Attached to Project: Arch Linux
Opened by hopimet (hopimet) - Sunday, 17 April 2016, 06:53 GMT
Last edited by Andreas Radke (AndyRTR) - Tuesday, 04 May 2021, 12:34 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Tobias Powalowski (tpowa)
Architecture i686
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 5
Private No


Description: After upgrade to smbclient 4.4.2-1 I am unable to connect to a samba share with a file browser (I tried thunar, dolphin or pcmanfm). The connection window asks for a login and password user but does not connect and does not return any error message. When I enter the login and password it returns to the connection window and asks for a password again and again...

It is important to note that I can mount this samba share in a terminal (mount -t cifs works fine).

Downgrading to smbclient 4.4.0-1 and libwbclient 4.4.0-1 solved the problem

Additional info:
* package version(s) : smbclient and libwbclient 4.4.2-1

Steps to reproduce:

Upgrade smbclient to version 4.4.2-1 and connect to a samba share via a file browser.
This task depends upon

Closed by  Andreas Radke (AndyRTR)
Tuesday, 04 May 2021, 12:34 GMT
Reason for closing:  Fixed
Additional comments about closing:  assuming this has been fixed for a long time...
Comment by Alex Theotokatos (alex.theoto) - Tuesday, 19 April 2016, 11:03 GMT
Same here.
Also, with smbtree I get some random error:
mkdir failed on directory /var/cache/samba: Permission denied

If I create this directory, I get no error but still doesn't connect.
On doublecmd I get forced to use username.
Comment by Andrew Gaydenko (student975) - Tuesday, 19 April 2016, 11:14 GMT
Not sure it is related to the issue, but may be. After last updates my autofs-based mounting of samba-running NAS (also Arch) shares was broken. After playing with mount options I have found it starts to work after removing "sec" option from the options list.
Comment by mrK (krow7) - Wednesday, 20 April 2016, 12:59 GMT
Have the same issue after the update to package version(s) : smbclient and libwbclient 4.4.2-1.
Reverting to previous version solved the issue.
Comment by Fischer (johnson) - Monday, 25 April 2016, 17:32 GMT
Had an issue printing on windows shared printer. After downgrading to smbclient-4.4.0-1-x86_64 and libwbclient-4.4.0-1-x86_64 printing worked again.
The Error Message in CUPS was: "Session setup failed: NT_STATUS_ACCESS_DENIED"
Comment by Alex Theotokatos (alex.theoto) - Monday, 25 April 2016, 18:07 GMT Comment by Knah Tsaeb (Knah-Tsaeb) - Monday, 02 May 2016, 09:44 GMT
You can add "client use spnego = no" in first line of "global" section in your smb.conf.
That work for me.
I find this in AskUbuntu http://askubuntu.com/questions/758860/samba-share-user-password-error-after-update

Good luck
Comment by mrK (krow7) - Wednesday, 04 May 2016, 07:30 GMT
@KnahTsaeb: This is not a solution since many people to not have Samba server installed on Arch.
Comment by Alex Theotokatos (alex.theoto) - Wednesday, 04 May 2016, 17:34 GMT
Is there any relation with 'badlock'?
If so, maybe the windows server is not updated and there is an incompatibility between smbclient and win server.

In my case, I try to connect to win xp computer. It is difficult to debug smbclient because it is at my work. If I find some time I'll try to debug it.
Comment by Olivier Brunel (jjacky) - Wednesday, 04 May 2016, 17:54 GMT
It should have been fixed upstream, so you might wanna wait until the package gets updated to 4.4.3 (or compile it yourself) first.
Comment by hopimet (hopimet) - Sunday, 08 May 2016, 17:36 GMT
@Knah Tsaeb: I have seen this workaround but it doesn't work for me. My samba server is installed on a raspberry running raspbian.
As proposed by Olivier Brunel, I'll wait the next update. I think the easier way to deal with this bug is to downgrade the client.
Comment by Alex Theotokatos (alex.theoto) - Monday, 09 May 2016, 12:53 GMT
After the latest update 4.4.3, Still I cannot connect to Windows server.
Before the release, I tried to compile the 4.4.3 version but I had the same problem. I thought that there might need some patch so I waited the official release.
I compiled the 4.4.0 with the security patch and again the same problem.
Did something changed at login users?

I don't know if it is client's or server's problem.
Is it because I try to connect to Win Xp which is unsupported OS?

Can someone verify if the latest package works?
Comment by hopimet (hopimet) - Monday, 09 May 2016, 16:34 GMT
Same problem here. The bug persists after the upgrade to 4.4.3

I think the bug is related to the client, not to the server, because downgrading the client works, without changing the server configuration.
Comment by Tobias Powalowski (tpowa) - Tuesday, 10 May 2016, 09:16 GMT
The permission and authentification process has changed since 4.4.1 look at the changelogs.
I'm also affected by this issue and cannot connect from my win7 machines on my server.
Comment by mrK (krow7) - Tuesday, 10 May 2016, 14:56 GMT
The issue persists with the latest release of smbclient and libwbclient - 4.4.3-1.
Still asks for password when connecting to Windows network and shares.
Comment by Alex Theotokatos (alex.theoto) - Wednesday, 11 May 2016, 18:42 GMT
Many things have changed for 4.4.* and most of them are security patches.
At the history-log info they use technical meanings of what changed. (Which I cannot understand at all)

Is there something to write at the wiki for this? Maybe there is no more bug but we might have to configure the client to communicate right and secure.
Comment by hopimet (hopimet) - Wednesday, 11 May 2016, 19:13 GMT
My samba server is running on rasbian (jessie) and its version is 4.2.10. This would mean that there is an incompatibility with the 4.4.2 (or more) clients?

A workaround is proposed here (I have not tried) but this is far to be ideal for security, unless your samba share is only accessed from your local network.
"I ended up using quite a simple work-around (obvious now with hindsight), which was just to create a dummy guest account (i.e. a named account called "guest") and send an email out to my users. Not ideal, but I didn't end up needing to add it explicitly to my existing shares because simply signing in with a valid user was enough to bypass the bug."
Comment by mrK (krow7) - Thursday, 12 May 2016, 11:21 GMT
I apologise! The issue is solved (as of smbclient and libwbclient - 4.4.3-1)!
Edit - This works when connecting to password-less Windows network shares. Have not checked connections to Samba server.

Since the functionality has changed a bit I was confused as to how this works.

Now to login anonymously to a windows share all I had to do is - enter current USER password (instead of choosing "Connect anonymously" option).
Edit - actually it still works if one types anything in the place of the password... and the username can even be changed to anything... And it still works. By anything I mean literally anything - numbers, letters, symbols (I haven't tried emoticons :D).

Although it still poses problem, if for example the user doesn't know the password. But that is a different issue altogether.
Comment by hopimet (hopimet) - Thursday, 12 May 2016, 13:55 GMT

I still can't login either anonymously or as an identified user (registered in the samba database). Could you give the samba version of your server, please?
As I previously posted I suspect a compatibility problem between the new version of the client when used to an old version of the server. If so, may be the configuration of the server would need to be changed.
Comment by mrK (krow7) - Thursday, 12 May 2016, 14:35 GMT

I forgot to specify in the last comment that it works when connecting to password-less Windows network shares and not Samba server.
I edited the comment to include that.

Sorry I just realized that this bug was filed against Samba shares and not Windows shares. (facepalm)
Although it did affect both.
Comment by Alex Theotokatos (alex.theoto) - Friday, 13 May 2016, 05:27 GMT
I can confirm that I can connect on Win server with:
username: RANDOM
domain: RANDOM
password: RANDOM

where RANDOM is whatever word.
I think this might me a new bug for upstream...

Also, I don't have to use 'cifs' module (via modprobe) and no 'wins' at /etc/nsswitch.conf
Is this strange?
Comment by Tobias Powalowski (tpowa) - Friday, 02 September 2016, 07:55 GMT
I needed to setup my samba users again now it works fine.
Check smbpasswd and pdbedit for your users and try to recreate them.
And using no password option with smbpasswd broke it too, I had to use simple empty password and hit return on creation.