SELinux blocking Samba access to mounted volume despite samba_share_t

Question

I repurposed an old AMD A10 APU-based machine that was collecting dust in my basement to act as a NAS, and eventually some other light-duty tech work. It's running CentOS 8.1, the boot disk is a 340GB hard drive I had laying around, and I have a 2TB, 2-drive RAID-1 array I put together with mdadm intended to be used mainly for the NAS. The RAID array (/dev/md0) is mounted to /media/raid0 and inside is a directory called nas set to mode 777. I have this line in /etc/fstab:

/dev/md0    /media/raid0    ext4    defaults    0    0

Samba is set to share /media/raid0/nas as a share called "fileshare". Following the SELinux recipe for Samba, I applied the samba_share_t label recursively to /media/raid0/nas and made it permanent with the semanage command.

However, when I attempt to browse \\SERVER\fileshare on a Windows machine, it says it can't connect. When I try to access it with smbclient on the server, I get kicked out with NT_STATUS_BAD_NETWORK_NAME. Samba's logs show repeated errors saying canonicalize_connect_path failed for service fileshare, path /media/raid0/nas.

BUT, If I disable SELinux with setenforce 0, the share suddenly works like flipping a switch. No errors, I connect with no problems.

To recap:

/media/raid0/nas is the path being shared as fileshare
/media/raid0/nas is extremely permissive (mode 777)
I have applied the samba_share_t label to /media/raid0/nas and it's set to be done recursively in SELinux
I can connect to the share without issue if SELinux is disabled (setenforce 0).

Why is SELinux still blocking this share? I'll note that I also tried moving the mountpoint to /raid0 but got the same results.

Edit: I'm seeing entries like this in my audit logs:

time->Mon Nov  2 22:41:39 2020
type=AVC msg=audit(1604374899.147:1102): avc:  denied  { read } for  pid=8091 
comm="smbd" name="/" dev="md0" ino=2 scontext=system_u:system_r:smbd_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir permissive=1

@MichaelHampton I turned SELinux back on, ran `tail -f /var/log/audit/audit.log` and it doesn't add any entries to the log when I try to access the share. — p0lar_bear, Nov 03 '20 at 00:22
If it's happened before, then there ought to be audit log entries already. In any case, if the problem happens when the client is trying to connect, then that's what you need to attempt. — Michael Hampton, Nov 03 '20 at 02:01
What filesystem did you use for `/media/raid0/nas`? And what are the mount options you set in `/etc/fstab` for it? — Michael Hampton, Nov 03 '20 at 04:07
Added my fstab entry to the post - it's an ext4 filesystem with default options — p0lar_bear, Nov 03 '20 at 04:10

score 1 · Accepted Answer · answered Nov 03 '20 at 04:15

The audit log entry says your mount point /media/raid0 doesn't have an SELinux label. Nevermind the nas directory, it can't get that far!

You'll need to set an appropriate SELinux context for /media/raid0. Restoring the default context mnt_t should be sufficient.

restorecon -v /media/raid0

score 0 · Answer 2 · answered Nov 03 '20 at 04:17

0

looks like it tries to descend starting from the root, inode=2, dir name=/. Means you either need to adjust the permissions accordingly from the top or put samba into a chroot-like namespace environment where same restrictions are to be loosen.

answered Nov 03 '20 at 04:17

poige

9,171
2
24
50

(written on smartphone) – poige Nov 03 '20 at 04:17

SELinux blocking Samba access to mounted volume despite samba_share_t

2 Answers2