Super simple/super puzzling SMB problem

Networking Networking Software
1

On my small fedora laptop server, I’ve got an external drive with my plex library on it, shared with samba so people can add to it from wherever in the house. Today I went to add a second external drive for music - and I can’t make it work for the life of me!

The 2 drives are both USB, both formatted identically (GPT, EXT4, one partition each). Permissions on the files, drives, mount points are set identically (777). I’ve found in the past that samba doesn’t like using the root of a drive as a share, so I’m not doing that. The smb.conf for each share is identical, but for the paths to the shares.

Alas, the plex drive is visible/readable/writeable as you’d expect, and the music one is not, so matter what I try. Changing the mount point doesn’t seem to help, but just making a directory /mnt/test/tunes_share makes the share appear just fine. I can’t imagine what it is about this drive that’s causing the issue?

I’ve been restarting smb between changes to confs, remounted drives in lots of interesting and different ways (currently they’re both mounted the same way in fstab), googling extensively, and I’m officially stuck.

smb.conf is below. I’m so intensely befuddled now, I’d really appreciate some assistance!

[global]
        map to guest = Bad User

        log file = /var/log/samba/%m
        log level = 1

        security = user
        passdb backend = tdbsam
        unix extensions = no
        wide links = yes
        follow symlinks = yes

[plex]
      	path = /mnt/2TB/media
        read only = no
        guest ok = yes
        writeable = yes
        create mask = 777
        browsable = yes

[tunes]
       	path = /mnt/music/tunes_share
        read only = no
        guest ok = yes
        writeable = yes
        browsable = yes
        create mask = 777
2

Can you ls -l /mnt/music/ for me?

Also you can use testparm as a sanity check for your smb.conf

1 Like
3 
    total 20
    drwxrwxrwx. 2 root root 16384 Oct 13 20:49 lost+found
    drwxrwxrwx. 2 jake jake  4096 Oct 13 22:00 tunes_share

testparm didn’t report anything untoward

4

That’s funky. I had problems with shares in fedora before but it was in my home dir. Bakes my noodle that it doesn’t work.

@nx2l you got anything?

1 Like
5

Whenever you deal with Fedora or RedHat or CentOS you need to remember SELinux. Personally I love having it. For example, with the recent Exim vulnerability I knew nobody would be breaking into read my home directory files or /etc/shadow.

So anyway, check your system log for file rejections when you try to use the share.

Also, any Samba share that isn’t in your home directory might have to be marked with the samba_share_t type. Or you could use setsebool samba_export_all_rw true. Or just to see if that’s the problem at all try running setenforce 0 then try the share. If that works then figure out how to fix it for real and reboot to make sure it took permanently.

Don’t just turn it off though. SELinux is incredibly useful.

It looks like this link covers it too: https://unix.stackexchange.com/questions/391673/sharing-a-mounted-drive-with-samba-on-centos7
And this: https://linux.die.net/man/8/samba_selinux

And I was wrong about the unconfined boolean. That’s apparently for scripts. Try setsebool samba_export_all_rw

4 Likes
6

I’ve always been a bit unsure about how to use SELinux so I didn’t think to mess with it. As per that link, ps -eZ | grep smbd_t showed me that samba_selinux was indeed dictating samba’s privileges. Running setsebool -P samba_export_all_rw 1 to allow samba to share all dir’s as rw and rebooting caused the share to appear on the network as expected! Thanks very much @zlynx, this was driving me mad. I’ll take this experience as a nudge to get to grips with SELinux a bit better!

2 Likes