Missing SELinux Permissions Samba Share (systemd mount)

Ask Fedora
,
1

I have a couple Samba client automount shares configured on my Fedora 44 KDE x86_64 workstation. Lately I noticed that deleting files in the share on the client in Dolphin no longer moved these files into the Trash folder on that particular share starting around March 2nd (I update daily). Instead Dolphin warns me with the following when I delete files: “The trash is not available for this item’s location. Permanently delete it instead?”

I dug a little deeper and noticed that the Samba share was not being mounted with any SELinux permissions which may be the issue:

ls -aZl /mnt/fileserver/share/tmp/
total 224
drwxr-x--- 2 user user ?     0 Mar 16 15:49 .
drwxr-x--- 2 user user ?     0 Mar 16 20:42 ..
-rw-r----- 1 user user ?  1782 Apr  1  2025 ansible_check_mode.txt

SELinux is enforcing, so I added a context=system_u:object_r:cifs_t:s0 option to the systemd mount file, ran a systemd daemon-reload , then unmount/mounted the share again. However, SElinux permissions are still missing. Systemd mount file for posterity:

$ sudo cat /etc/systemd/system/mnt-fileserver-share.mount 
[Unit]
After=network-online.target
Description=Mount fileserver.domain share
OnFailure=automount-restarter@%N.service

# nobrl option added for Calibre library support
[Mount]
What=//fileserver.domain/share
Where=/mnt/fileserver/share
Type=cifs
Options=auto,nobrl,rw,x-systemd.device-timeout=5,file_mode=0640,dir_mode=0750,vers=3.11,uid=10000,gid=10000,nofail,credentials=/etc/fstab.d/creds.conf,_netdev,context=system_u:object_r:cifs_t:s0
DirectoryMode=0750

[Install]
WantedBy=multi-user.target

Does this need a bugzilla report or is it a known issue? Would be nice to confirm with someone else that they’re seeing the same behavior on their Samba shares first.

2

I don’t think SELinux would be the problem in the case you describe. Wouldn’t Dolphin be running unconfined? You can use ps -eZ to list out what SELinux context the processes are running under.

1 Like
3

Yeah, dolphin is running unconfined:

$ ps -eZ | grep dolphin
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 66825 ? 00:00:27 dolphin

I enabled the samba recycle VFS feature for now on the samba shares which is a partial fix. Ironically, this reddit post details the behavior before that I want (though the user who submitted did not want the Trash bin functionality): https://www.reddit.com/r/kde/comments/1d376uy/deleting_a_file_in_dolphin_on_a_mounted_smb_share/

4

I think they actually changed the default behavior to where if you want the trashcan on a samba mount you have to set up recycle vfs. Which it used to behave like that several years ago.

5

No, it appears to be a permissions issue of some sort:

Mar 18 11:45:17 client kioworker[184649]: Creating trash for "/" failed - no permission?

edit:

If the ~/.Trash-${uid} folder does not exist, the error is as follows:

Mar 18 11:52:24 client kioworker[3471]: Creating trash for "/" failed - no permission?
Mar 18 11:52:24 client kioworker[3471]: could not create "/mnt/fileserver/user/.Trash-10000/info"
Mar 18 11:52:24 client kioworker[3471]: Directory "/mnt/fileserver/user/.Trash-10000" exists but didn't pass the security checks, can't use it

Which is odd, because the .Trash folder is not created despite kioworker saying that it does. If I manually create the ~/.Trash-${uid} folder, then I get the first error I reported:

Mar 18 11:56:26 client kioworker[6823]: Creating trash for "/" failed - no permission?
8

well they restricted root. uid/gid should be greater than 1000 unless you set the -force user =root in smb config. That might be what you are running into with this.

even though it should be a user uid/gid on the samba host instead of root because file permissions are going to fallow this so any files created remotely are going to be in the group root instead of users.

9

I believe it’s a regression in kf6-kioworker. Downgrading from 6.24.0 to 6.23.0 fixes the issue. Found a related bug here: https://bugs.kde.org/show_bug.cgi?id=490247

Since it’s not necessarily the same issue as mine, I submitted a bug report of my own here: https://bugs.kde.org/show_bug.cgi?id=517795

1 Like
10

Its just enforcing the rule that root is not a system user. Just like root is not supposed to be used as a desktop user. So it would be interesting what they will say about your bug when they had to make an override so root privileges could be used over samba. Root usually does not have a trashcan either in most if not all Linux distributions.

11

@oconical

well they restricted root. uid/gid should be greater than 1000 unless you set the -force user =root in smb config. That might be what you are running into with this.

UID/GID are set to 10000 both on the share itself (on the samba server) and locally on the samba client. 10000 > 1000, so I don’t think this comment is relevant.

edit:

If it matters, the samba username matches the local username on the samba server. Likewise, the local username on the samba client also matches the remote username. The UIDs/GIDs also match on both server/client.

Here’s the sanitized server’s smb.conf:

[global]
        workgroup = WORKGROUP
        server string = fileserverfqdn
        netbios name = fileserverhostname
        interfaces = "lo" "enX0;capability=RSS,speed=10000000000"
        log file = /var/log/samba/log.%m
        max log size = 50
        security = user
        passdb backend = tdbsam
        domain master = yes
        local master = yes
        os level = 255
        preferred master = yes
        wins support = yes
        dns proxy = yes
        load printers = no
        disable spoolss = yes
        cups options = raw
        printcap name = /dev/null
        printing = bsd
        use sendfile = yes
        aio write behind = yes
        allow insecure wide links = yes

        [username]
        path = /home/username
        browseable = yes
        writeable = yes
        valid users = username
        create mask = 0644
        directory mask = 0755
        guest ok = no
        follow symlinks = yes
        wide links = yes

Permissions on the share (samba server):

$ ls -lZ /home/
total 4
drwx------. 22 username username system_u:object_r:user_home_dir_t:s0 4096 Mar 18 16:36 username

User/Group IDs on the samba server:

$ cat /etc/passwd | grep username
username:x:10000:10000::/home/username:/bin/bash
$ cat /etc/group | grep username
username:x:10000:

User/Group IDs on the samba client:

$ cat /etc/passwd | grep username
username:x:10000:10000:My Name:/home/username:/bin/bash
$ cat /etc/group | grep username
username:x:10000:

Lastly, the smbpasswd user:

$ sudo pdbedit -L -v
---------------
Unix username:        username
...