0

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
Improve this question
6
  • Check the audit log. Commented Nov 2, 2020 at 19:24
  • @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. Commented Nov 3, 2020 at 0: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. Commented Nov 3, 2020 at 2:01
  • Added a relevant audit log entry to my post. Commented Nov 3, 2020 at 4:01
  • What filesystem did you use for /media/raid0/nas? And what are the mount options you set in /etc/fstab for it? Commented Nov 3, 2020 at 4:07

2 Answers 2

Reset to default
3

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
Improve this answer
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.

Improve this answer
1
  • (written on smartphone) Commented Nov 3, 2020 at 4:17

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.