Server not using user level security and no password supplied.
tree connect failed: NT_STATUS_WRONG_PASSWORD
That happens when trying to use smbclient to connect to a share. The weird thing is that I can authnenticate just fine from Windows XP.
It is partially my mistake, I forgot this share does have a password. I've tried authenticating with the correct user and also with "Guest" because this works in Windows. In Linux I get:
Server not using user level security and no password supplied.
Server requested LANMAN password (share-level security) but 'client lanman auth' is disabled
tree connect failed: SUCCESS - 0
A lot of places suggest adding this to the global portion of smb.conf on the server:
client lanman auth = Yes
It doesn't work in my case (yes SMB has been restarted), maybe because the client and servers are mixed.
Server=Centos 4: samba-3.0.28-0.el4.9
Client=Kunbuntu 8.04: 2:3.2.3-1ubuntu3.4
==========================
workgroup = OURHOUSE
domain master = no
#client lanman auth = Yes
#lanman auth = Yes
hosts allow = 192.168.1.
log file = /var/log/samba/smbd.log
max log size = 50
# security = user
# when I
security = user
encrypt passwords = yes
smb passwd file = /etc/samba/smbpasswd
unix password sync = Yes
#passwd program = /usr/bin/passwd %u
#passwd chat = *New*UNIX*password* %n\n *ReType*new*UNIX*password* %n\n *passwd:*all*authentication*tokens*updated*successfully*
guest account = hostmeister
socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
wins support = yes
printcap name = cups
printing = cups
cups options = "raw"
use client driver = yes
With security=user I can authenticate from the smbpasswd file from Linux to the password protected share.
But now in Windows I can't authenticate and I can't browse any shares at all.
This is why I used to have "security=share", because Windows users could view all the public shares without logging in, and they would only have to login in the case of a share that specified "valid users=someuser".
This is still not a very good solution at all.
Documentation I read says you can only have anonymous shares (security=share) or user level authenticated shares (security=user). I understand that part as it is obvious from the config file :)
The annoying thing is that I believe SAMBA is the culprit here. The client or server (whoever is most responsible for this mess) should be fixed.
In reality the method security=share method makes the most sense. Why? Because the anonymous shares can be easily accessed by the public which is the intended functionality.
And when connecting from a Windows client, it seems to automatically send the username as one of the allowed users and accepts the password for protected/private shares.
The only very annoying issue, is that we can see above that Linux Samba clients won't be able to do this, whether you specify the correct username and password or not.
It seems like the Windows SMB client and Samba Unix client's access things differently. It also could be that either/or the Samba Server and Client see that the "public" security option is set and refuse to accept or authenticate with any password, which is a really stupid and undesired kind of behavior.
This explains the message "Server requested LANMAN password (share-level security) but 'client lanman auth' is disabled" coming up from the Samba client even though the "client lanman auth" options were enabled. I guess in effect the mechanism to authenticate from a Unix Samba client is made impossible once you set the security=share.
I spent hours wondering why my main Windows client could not longer connect to the share, it was just saying I dont' have permission and even when prompting for a password nothing worked.
I found that Windows caches the way it authenticates or the password it sends or some other strange thing. Rebooting made it authenticate properly and accept the password so I could get to the shares.
You can run this to delete all connections: net use * /delete
samba, smb, server, user, password, supplied, nt_status_wrong_passwordserver, nt_status_wrong_password, smbclient, authnenticate, xp, partially, ve, authenticating, quot, linux, requested, lanman, auth, disabled, adding, global, portion, conf, doesn, restarted, servers, centos, kunbuntu, ubuntu, workgroup, ourhouse, domain, hosts, var, smbd, encrypt, passwords, passwd, etc, smbpasswd, unix, sync, usr, bin, retype, authentication, tokens, updated, successfully, hostmeister, socket, tcp_nodelay, so_rcvbuf, so_sndbuf, printcap, cups, printing, authenticate, browse, shares, users, logging, login, specified, valid, someuser, allows, mode, documentation, authenticated, config, culprit, method, accessed, functionality, connecting, automatically, username, accepts, specify, undesired, enabled, mechanism, pitfall, dont, prompting, caches, authenticates, rebooting, delete, connections,