Unable to connect to my SMB share - permission denied

I set up a samba server on my laptop for family members. The setup is like this:

Added a separate user for share called shareuser with uid=250
Added the user to the smb database, password set up: sudo smbpasswd -a shareuser
Created a group for the smb share and added the user to it:

groups shareuser                                                            
shareuser : shareuser smbgroup1

Set the SELinux context properly, changed group ownership to smbgroup1 (recursive):

drwxrwx---.  6 my-username smbgroup1 system_u:object_r:samba_share_t:s0 4096 Feb  4  2022  .
drwx--x---+ 17 my-username my-username     system_u:object_r:mnt_t:s0   4096 Sep  2 11:15  ..
drwxrwxr-x. 20 my-username smbgroup1 system_u:object_r:samba_share_t:s0 4096 Sep  3 18:16 foo1
drwxrwxr-x.  8 my-username smbgroup1 system_u:object_r:samba_share_t:s0 4096 May 14 19:34 foo2
drwxrwxr-x. 11 my-username smbgroup1 system_u:object_r:samba_share_t:s0 4096 Aug 27 16:19 foo3
drwxrwxr-x.  9 my-username smbgroup1 system_u:object_r:samba_share_t:s0 4096 Jan 30  2022 foo4

relevant smb.conf part:

        comment = <comment>
        path = <path>
        writeable = yes
        guest ok = no
        valid users = @smbgroup1
        force create mode = 774
        force group = smbgroup1
        force directory mode = 770
        inherit permissions = yes

And restarted the samba daemon, but no matter what I keep getting permission denied when trying to log in

sudo tail /var/log/samba/log.smbd
[2022/09/03 18:27:03.885867,  0] ../../source3/smbd/service.c:168(chdir_current_service)
  chdir_current_service: vfs_ChDir(<path>) failed: Permission denied. Current token: uid=250, gid=1002, 2 groups: 1001 1002
[2022/09/03 18:27:04.293680,  0] ../../source3/smbd/service.c:168(chdir_current_service)
  chdir_current_service: vfs_ChDir(<path>) failed: Permission denied. Current token: uid=250, gid=1002, 2 groups: 1001 1002
[2022/09/03 18:27:04.297128,  0] ../../source3/smbd/service.c:168(chdir_current_service)
  chdir_current_service: vfs_ChDir(<path>) failed: Permission denied. Current token: uid=250, gid=1002, 2 groups: 1001 1002
[2022/09/03 18:27:04.615441,  0] ../../source3/smbd/service.c:168(chdir_current_service)
  chdir_current_service: vfs_ChDir(<path>) failed: Permission denied. Current token: uid=250, gid=1002, 2 groups: 1001 1002
[2022/09/03 18:27:04.671344,  0] ../../source3/smbd/service.c:168(chdir_current_service)
  chdir_current_service: vfs_ChDir(<path>) failed: Permission denied. Current token: uid=250, gid=1002, 2 groups: 1001 1002

Also no SELinux problem:

sudo grep denied /var/log/audit/audit.log
type=AVC msg=audit(1661769921.811:363): avc:  denied  { append } for  pid=1385 comm="sddm-helper" name=".Xauthority" dev="nvme0n1p3" ino=2360589 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:unlabeled_t:s0 tclass=file permissive=0

In theory it should work but it isn’t working, is it something to do with SELinux or some form of access control I’m not aware of?

Did you open all the relevant ports in firewalld?

I allowed the samba and samba-client services in firewalld.
Interesting findings: I used su to login as the shareuser, I can’t cd into the shared folder.


That’s weird, shareuser is part of the smbgroup1 that has rwx on the shared folder, an I missing something?

uid=250(shareuser) gid=1001(shareuser) groups=1001(shareuser),1002(smbgroup1) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

What is causing the permission to be denied? Everything looks ok.

That might possibly be related to some se-linux policy of which I can’t say much, as I’m lacking any “insight” into this. It is “over-my-head”, sorry.

Shouldn’t it be so, checking all permissions on folders and files is what could be causative, as well, as you already thought, afaiu.

Is this ok?
Does the upper path has the right permissions for the smbgroup1 group? :thinking:
Assuming a path like “/a/b/c”, despite if “c” has the correct permissions (i.e. x for the group), but if “b” or “a” doesn’t allow the group to cross the path, to reach the “c” directory, probably it could be the issue.

I went extreme and chmod 777 for the /mnt/sda1 directory (not recursive)

sudo su shareuser
bash-5.1$ cd /mnt
bash-5.1$ ls -l
total 8
drwxrwxrwx+ 17 my-username smbgroup1 4096 Sep  2 11:15 sda1
bash-5.1$ cd sda1
bash: cd: sda1: Permission denied

I added my user to the smbgroup1 and added an smb password. I can login using my own user but not shareuser. This is not a satisfactory solution.
It seems that shareuser is unable to cd into a mounted partition.

The output of ls on /mnt/sda1 shows a plus sign. This plus sign indicates the usage of an ACL (access control list).

Could you provide the result of this command?
getfacl /mnt/sda1

getfacl /mnt/sda1
getfacl: Removing leading '/' from absolute path names
# file: mnt/sda1
# owner: my-username
# group: smbgroup1

Edit: I finally fixed it! I removed the special ACL. I don’t understand it fully yet but I removed the mask of the group and the mysterious user 107 and 64055 (doesn’t exist in /etc/passwd), then set up the permissions properly. Now I can cd via shareuser!

I used the advanced permissions tab of Dolphin to fix this mess, I will learn the cli version of it later.

The correct permissions now set:
drwxr-x---. 17 my-username smbgroup1 4096 Sep 2 11:15 sda1

Thanks everyone!


Glad, you’ve got it solved!


That makes sense. The mask limits what can be set, so a mask of rwx effectively means no perms.

What confused me is that the ls -l was showing rwx for the group yet I still got permission denied.
I also still can’t understand how these ACLs were set. The user IDs aren’t even in my /etc/passwd. Should I be concerned?

Edit: The UID 64055 is related to libvirt.

Mask effectively subtracts from the ACLs, so even though you had ACLs set, they were negated by the mask.

You didn’t mention how you are connecting/mounting the share.

Using the static IP I assigned to my device + login credentials and any samba client works. It works on private networks only, not internet routable. I just block incoming SMB connections on public network using the firewall.

The issue is solved so I don’t want to keep bumping it up for nothing.


I would really appreciate if someone has a link to an explanation of the design philosophy of the acl’s. If I understood the “man acl” correctly, the user and other parts of “ls -l” are identical to user and other in getfacl, but the group part is identical to the mask. And apparently the effective group permissions are defined by setfacl. Without knowledge of the + in “ls -l” this can be highly confusing…


Edit: found already something:


So the idea is to be able to limit the access rights of group plus all users and groups mentioned in the access lists by chmod, which in this case changes the mask and not the group permission. Tricky in case some program creates access lists while only having knowledge of standard unix permissions.

If you have any further questions about this, please create a new topic for it since this one has already been marked solved. That said, learning how ACLs work is very important if you want to do any system administration work and I hope you’ll keep exploring it.