Samba unable to open certain path

I’m trying to set up some SAMBA share. I followed the guide in the docs, and succesfully set up a share /home/user/Public/samba.

Now I’m trying to set up a second share /mnt/data/share/samba, I followed all the same steps, but I’m unable to open this share while the first share works fine.

In journalctl it’s shown that it’s something with SELinux context:

Apr 17 16:30:12 fedora audit[3725]: AVC avc:  denied  { search } for  pid=3725 comm="smbd" name="/" dev="dm-1" ino=256 scontext=system_u:system_r:smbd_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir permissive=0
Apr 17 16:30:12 fedora audit[3725]: AVC avc:  denied  { search } for  pid=3725 comm="smbd" name="/" dev="dm-1" ino=256 scontext=system_u:system_r:smbd_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir permissive=0
Apr 17 16:30:12 fedora smbd[3725]: [2023/04/17 16:30:12.627750,  0] ../../source3/smbd/smb2_service.c:787(make_connection_snum)
Apr 17 16:30:12 fedora smbd[3725]:   make_connection_snum: canonicalize_connect_path failed for service LinuxHost, path /mnt/data/share/samba

However, ls -lZ /mnt/data/share shows that the SELinux context is correct?

drwxr-xr-x. 1 user user unconfined_u:object_r:samba_share_t:s0 48 17. Apr 15:32 samba

Full /etc/samba/smb.conf:

# See smb.conf.example for a more detailed config file or
# read the smb.conf manpage.
# Run 'testparm' to verify the config is correct after
# you modified it.
#
# Note:
# SMB1 is disabled by default. This means clients without support for SMB2 or
# SMB3 are no longer able to connect to smbd (by default).

[global]
	workgroup = SAMBA
	security = user

	passdb backend = tdbsam

	printing = cups
	printcap name = cups
	load printers = yes
	cups options = raw

	# Install samba-usershares package for support
	include = /etc/samba/usershares.conf

        min protocol = SMB3

[homes]
	comment = Home Directories
	valid users = %S, %D%w%S
	browseable = No
	read only = No
	inherit acls = Yes

[printers]
	comment = All Printers
	path = /var/tmp
	printable = Yes
	create mask = 0600
	browseable = No

[print$]
	comment = Printer Drivers
	path = /var/lib/samba/drivers
	write list = @printadmin root
	force group = @printadmin
	create mask = 0664
	directory mask = 0775

[Public]
        comment = My Share
        path = /home/user/Public/samba
        writeable = yes
        browseable = yes
        public = yes
        create mask = 0644
        directory mask = 0755
        write list = user

[LinuxHost]
        comment = Host Share
        path = /mnt/data/share/samba
        public = yes
        writable = yes
        browseable = yes
        create mask = 0644
        directory mask = 0755
        write list = user

Upon more testing, it seems that using any directory in the second drive (mounted on /mnt/data) will get this error. I can set up any directory under / or /home and those work fine, but anything under /mnt/data do not.

I’m not sure what causes this.

For more context:

  • / and /home are subvolumes of BTRFS on a NVMe drive, encrypted with LUKS.
  • Another (separate) NVMe drive, also BTRFS encrypted in LUKS, has subvolume share, and the root subvolume is mounted on /mnt/data. samba is a normal folder in the subvolume share.

It seems that the problem is only on this second drive.

/etc/fstab:

UUID=e242fb58-2a32-4763-ae57-8225c82d738d /                       btrfs   subvol=root,compress=zstd:1,x-systemd.device-timeout=0 0 0
UUID=bdf23158-1686-47e8-9919-0503e66564b3 /boot                   ext4    defaults        1 2
UUID=73BA-717B                            /boot/efi               vfat    umask=0077,shortname=winnt 0 2
UUID=e242fb58-2a32-4763-ae57-8225c82d738d /home                   btrfs   subvol=home,compress=zstd:1,x-systemd.device-timeout=0 0 0
UUID=8a9444d1-dc3c-4a8e-ba59-df1019c67a3a /mnt/data               btrfs   compress=zstd:1,x-systemd.device-timeout=90,x-gvfs-show,nofail 0 0

Also, if I run sudo setenforce 0, then I can access it. So it’s definitely SELinux problem.

Thanks for the link.

I ran sudo audit2allow -w -a:

type=AVC msg=audit(1681857418.034:270): avc:  denied  { search } for  pid=4509 comm="smbd[127.0.0.1]" name="/" dev="dm-1" ino=256 scontext=system_u:system_r:smbd_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir permissive=0
	Was caused by:
	One of the following booleans was set incorrectly.
	Description:
	Allow samba to export all ro

	Allow access by executing:
	# setsebool -P samba_export_all_ro 1
	Description:
	Allow samba to export all rw

	Allow access by executing:
	# setsebool -P samba_export_all_rw 1

It suggests me to use setsebool -P samba_export_all_rw 1. Doesn’t this make the samba server insecure? It also doesn’t solve the root problem that is audit showing a different SELinux context than what is show in ls -lZ, just works around it by effectively disabling SELinux for samba.

Try to restore file labeling recursively as explained here:
Troubleshooting SELinux - Fedora Magazine

With restorecon -r? I already done that multiple times. It’s also in the guide I followed (that I posted in the first post of this thread).

I’ve also tried fixfiles onboot. None of them works.

1 Like
ls -l -d -Z /{,mnt/{,data/{,share/{,samba}}}}

What is the output?

dr-xr-xr-x. 1 root    root    system_u:object_r:root_t:s0            178 19. Apr 01:57 /
drwxr-xr-x. 1 root    root    system_u:object_r:mnt_t:s0               8 19. Jan 01:00 /mnt/
drwxr-xr-x. 1 user    user    system_u:object_r:unlabeled_t:s0        42 18. Apr 23:51 /mnt/data/
drwxr-xr-x. 1 user    user    system_u:object_r:samba_share_t:s0      30 19. Apr 01:37 /mnt/data/share/
drwxr-xr-x. 1 user    user    unconfined_u:object_r:samba_share_t:s0  48 17. Apr 16:50 /mnt/data/share/samba

/mnt/data/share/ has samba_share_t because I previously wanted to use that as the path for the samba share, it didn’t work, so I created a subfolder samba within it to try, it still doesn’t work.

Try this:

sudo chcon -t samba_share_t /mnt/data

OK, now it works!

But why does /mnt/data need to have the context set, when I’m only accessing /mnt/data/share/samba?

There’s a known issue that Samba requires recursive permissions up to the top level, so it seems to apply to SELinux labels as well.

Because the part you are accessing is controlled by the path to reach it.
Linux standard permissions work similarly.