Samba SMB Error - Server not using user level security and no password supplied. tree connect failed: NT_STATUS_WRONG_PASSWORD -

Samba SMB Error - Server not using user level security and no password supplied. tree connect failed: NT_STATUS_WRONG_PASSWORD

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

==========================

Working/Broken Current smb.conf File:

  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.

Samba Allows One Security Mode At A Time

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. 

One Pitfall In Windows To Avoid

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
 


  • How to disable Google Fonts in Wordpress
  • Unable to load dynamic library /usr/lib64/php/modules/php_openssl
  • mysqld in Linux hacked
  • W: GPG error: http://archive.debian.org squeeze Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY AED4B06F473041FA NO_PUBKEY 64481591B98321F9
  • cannot mount kvm ntfs image
  • h264 DVR security camera footage cannot be played
  • dhcpd.conf how to secure so only known and allowed clients will be given dhcpd IP address leases
  • Thunderbird E-mail List Blank White but e-mails still clickable and viewable
  • css responsive images
  • responsive table without changing much code solution
  • yum how to install old obsolete packages
  • PHP Howto Store Value of Included File Output Into Variable
  • PHP Migration from 5.3 to 5.4+ and dealing with deprecated functions
  • ffmpeg vidstab to stabilize video
  • userdel user userdel: cannot lock /etc/passwd; try again later.
  • mdadm how to mount inactive array
  • How to find and mount mdadm arrays automatically
  • M2Crypto.SSL.Checker.WrongHost: Peer certificate subjectAltName does not match host, expected fedora-archive.ip-connect.vn.ua, got DNS:mirror.ip-connect.vn.ua
  • [Wed Sep 20 15:34:44 2017] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) [Wed Sep 20 15:34:44 2017] [error] Init: Unable to read server certificate from file /www/ssl-certs/server.crt [Wed Sep 20 15:34:44 2017] [error] SSL Library Err
  • linux how to answer yes to copy