smbclient NT_STATUS_ACCESS_DENIED

Question

About once every 10 years I need to wrestle with SAMBA as I migrate to new hosts, and then I repress the traumatic memory until I have to relearn it all the next time :S Hence this newbyish question.

I have a Ubuntu VM with a couple of shares - one ("Public") is unsecured, the other ("Public2") is secured, with the intention that it should be accessed only by an authenticated user account defined on the Ubuntu box. Both shares appear in Windows Explorer on both XP and Win8.1. However, I can't for the life of me work out how to log into the secure Public2 share.

Leaving Windows clients out of it, I've tried simply looping back to the box using smbclient, which produces the following output, indicating it just can't authenticate:

michael@ubuntu:~$ smbclient //ubuntu/Public2 --user=michael%mypasswd
Domain=[WORKGROUP] OS=[Unix] Server=[Samba 4.1.6-Ubuntu]
tree connect failed: NT_STATUS_ACCESS_DENIED

Meanwhile the unsecured share is accessible. What (probably incredibly obvious) thing have I missed? Am I not specifying the username correctly?

/var/lib/samba/usershares/public (unsecure, works) contains:


#VERSION 2
path=/home/michael/Public
comment=
usershare_acl=S-1-1-0:F
guest_ok=y
sharename=Public

/var/lib/samba/usershares/public2 (which I can't access) contains:

#VERSION 2
path=/home/michael/Public2
comment=
usershare_acl=S-1-1-0:F
guest_ok=n
sharename=Public2

Mcdougall

I got the same error as the title of the OP, however due to a completely different issue: The directory name I was trying to move into (with cd command) was not proper (due to the spaces in the directory name). When I used the quotes it worked. I am writing here as it might be relevant for other users ending up in this post for the same reason. – Lobule

Answer 1

WARNING: This refers to Samba 2. We are at Samba 4 now. Take care which version of Samba you are using. As stated in my comment, the GUI will break your configurations.

A work colleague has pointed me in the right direction:

The Linux user ID being used to access the Linux share needs to have a second "samba" password defined for it. The easiest way to do this is to install and run the GUI Samba Server Configuration app, which isn't installed by default.

The Samba documentation does explain this, but it's buried in the masses of documentation explaining all the various arcane aspects of samba.conf configuration etc.

The following article gets to the heart of the subject:

http://ubuntuhandbook.org/index.php/2014/05/ubuntu1404-file-sharing-samba/

Mcdougall

Great answer. I had the same problem as the OP of once every few years having to re-learn samba stuff. With this the basic answer is to use Samba Server Configuration and then restart smbd and nmbd. And in my case port forward port 445 to the Mac client. – Legislature

DO NOT INSTALL THE GUI SAMBA SERVER CONFIGURATION APP. It's supporting only Samba 2 and we are now @ Samba 4. It will break all your configurations. – Photographer

Answer 2

For users who are using for the command line option, use

$ sudo smbpasswd -a <user_name>

this will prompt you to assign the password.

Roister

Answer 3

You have to edit the '/etc/samba/smb.conf' use sudo nano /etc/samba/smb.conf to edit the conf file. Where Workgroup = [your Domain]

Strophanthin

Answer 4

There is no 'second samba password'. There is linux password: /etc/passwd and then there is Samba password, which is either smbpasswd or passdb.tdb. Which one and where it is located depends on Samba version and setting in smb.conf. BOTH must be set. Both means Linux in /etc/passwd and in Samba (one of the above). This is in most cases the issue with this error message. Or try to restart Lanman service, or Windows.
But I want to comment on another, probably rarer case.

If you are using customized Samba and only in such case, there might be another (extended) reason for this error.
Samba might be compiled with additional permission checks, which will say "NO" (return false) after which Samba will announce error, the same as this Q is mentioning.
Check the log for errors. There might be a clue if it is such a case.

Again, this is specific for custom build Samba.

Specifically in my case, on QNAP NAS, Samba will call a binary /sbin/appriv -C -u 502 -S1

   -C, --check                     Check user privilege.
   -S, --samba [bit]               The privilege of Samba
   -u, --uid [uid]                 UID.

appriv is "appriv -> nasutil" which is QNAP own binary, not part of the linux or the GNU.

With so many options build in Samba, I can't find a reasoning for this additional check.
Especially when it could be satisfied with just a plain empty file returning "true".
Just a complication, possible source of issues, no safety advancement.

I've been updating old abandoned system from QNAP. Replaced Samba from another, newer NAS.
This is how I come about this issue and wasted a lot of time on it. Thanks QNAP.

Tacy

to comment on the edit: sure I understand the reason, but mine was a cutting edge case and as a such there is no specific place for it on SO. This is not "the right" answer and it was not meant to be. This is an answer for specific target group. I anticipated disagreement with my answer from most of the people reading this and in that spirit I added the ending, "hope this help someone" which is now removed. – Tacy

Answer 5

Apparmor might also be the cause. You need to whitelist all share locations, otherwise you will always get the "permission denied" error.

Fix is adding to /etc/apparmor.d/local/usr.sbin.smbd:

"/path_to_share/" rk,
"/path_to_share/**" lrwk,

for each share. (The first line allows read-access to the base-directory, the second line allows read-write-access to everything within that base-directory recursively)

Source: https://wiki.archlinux.org/title/Samba#Permission_issues_on_AppArmor
Crosspost from: https://serverfault.com/a/1109267/592032

Findley

Great wild guess, but first we'd have to determine that AppArmor is even involved. – Charlena

Answer 6

I had that problem when - on the server, the linux-user wasn't a member of the linux-group that I had used for the "force group" option in the smb.conf

So I had force groups = mygroup in my smb.conf, but $ groups myuser showed that myuser wasn't member of mygroup.

$ sudo usermod -a -G mygroup myuser

fixed it.

Insignificant