CIFS mount with UID and GID set reverts to root only permissions

Howdy y’all. I’ve got an SMB share on my network that I’ve mounted successfully on other machines on my network with this /etc/fstab entry:

192.168.1.5/shareddrive /mnt/shareddrive cifs rw,vers=3,x-systemd.automount,x-systemd.mount-timeout=10,_netdev,nofail,user,uid=1000,gid=1000,credentials=/etc/samba/credentials/shareddrive 0 0 

As you can see, I’ve set UID and GID, which on my other systems (openSUSE and Arch) means my user, having those IDs, has ownership of /mnt/shareddrive. And in fact, if I run sudo mount.cifs 192.168.1.5/shareddrive /mnt/shareddrive -o rw,vers=3,x-systemd.automount,x-systemd.mount-timeout=10,_netdev,nofail,user,uid=1000,gid=1000,credentials=/etc/samba/credentials/shareddrive, that’s exactly what I get on my Rocky 9.2 system as well. Until I reboot, that is. I’ve had a look at /var/log/messages and dmesg but can’t find a whole lot info here. Assuming I’m looking for the right thing.

Does anybody have an idea what I might be doing wrong here? Thanks so much!

Shouldn’t there be ‘//’ at the start of that mount line i.e. ‘//192.168.1.5/shareddrive

On the server, look in /var/log/samba/ and /var/log/security/ for error output.

I stopped using fstab entries for samba shares a few years ago because they became unreliable as the samba security became more onerous. The problem with troubleshooting this is that the mount succeeds but without the correct user perms so there may not be any easy error message.

You’re absolutely right, that was a copy/paste error, sorry. Doesn’t look like I can edit the post unfortunately

I’ve done a reboot of the VM and checked /var/log/samba, found only an empty directory called old. /var/log/secure shows nothing of note, just entries connected to me SSHing into the box.

Is there something you use instead of fstab entries? I’d messed around with systemd automount units but didn’t get too deep into it because I also use machines running Alpine or macOS and figured I should find a portable solution.

cifs-utils, contrary to popular conception, has nothing to do with Samba, so you wouldn’t find anything in the Samba logs.

I’m confused as to what is the server and what is the client. Clients won’t have samba log entries. If rocky is a client and it is on a vm then what is the vm and version? What is the OS and version of the server?
The fact that the mount works as expected on the commandline leads me to believe that it is a copy and paste error into fstab.

Sorry, I should have clarified really.

The server running the Samba share is on openSUSE Leap 15.6. The /var/log/samba on here does actually show a bunch of logs, including smbd.<ip address> and smbd.<hostname>, both sitting at 0 bytes. But as hortimech pointed out, that might not be worth looking at anyway.
The client I’m using as an example here is a Rocky 9.2 VM running on up to date Proxmox. However, I have also got a laptop running Rocky 9.2 which shows exactly the same issues. They are both configured using Ansible using the same playbooks, so they should in theory be set up identically. I’ve run these playbooks on Arch laptops and VMs and they don’t have this issue. I’ll try another distro to see if that makes any difference—I’m wondering if there are any Rocky-specific policies that might affect this at all? SELinux maybe? I only ask because I’ve heard it’s a thing and don’t know anything about it

As for the copy and paste error, I pasted from fstab into the command line, changing only the formatting, and it worked perfectly fine.

I wonder if this is a timing issue, is fstab trying to mount the share before the network is up ? try adding ‘noauto’ to the options in /etc/fstab and see if that helps.
If that doesn’t help, for testing purposes, try turning off Selinux and reboot, if your share mounts, then it’s Selinux. Once you know either way, turn Selinux on again.

Tried noauto but no effect, same with turning off Selinux.

I’ve also now updated to 9.4, but I’m sure that’s not relevant.

Thanks everyone for your help so far!

Compare the output of mount | grep "/mnt/sharedrive" to check if any other options are being applied when mounted manually and on reboot.
And also, just to troubleshoot, try removing x-systemd.automount to see if automounting applies wrong permissions.

I get these two lines grepping the output of mount:

systemd-1 on /mnt/shareddrive type autofs (rw,relatime,fd=55,pgrp=1,timeout=0,minproto=5,maxproto=6,direct,pipe_ino=2667)
//192.168.1.20/shareddrive on /mnt/shareddrive type cifs (rw,nosuid,nodev,noexec,relatime,vers=4.1.1,cache=strict,username=blorf,uid=1000,forceuid,gid=1000,forcegid,addr=192.168.1.20,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,reparse=nfs,rsize=4194304,wsize=4194304,bsize=1048576,retrans=1,echo_interval=60,actimeo=1,closetimeo=1,x-systemd.automount,x-systemd.mount-timeout=10,_netdev,user)

I’ve also removed x-systemd.automount, unmounted the drive and rebooted, but it still came back as owned by root

In the two grepped lines the things that stand out to me are:
minproto=5,maxproto=6,
and

vers=4.1.1

Where are those coming from?

Good question, seeing as ‘vers’ is referring to the version of SMB and the latest version is 3.1.1
Try removing ‘vers=3,’ from the fstab line, it is the default.

This is an interesting point, I’ve removed the vers=3 part from fstab as suggested by @hortimech and while the effect hasn’t changed, the output of mount has:
systemd-1 on /mnt/shareddrive type autofs (rw,relatime,fd=50,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=19362)

//192.168.1.20/shareddrive on /mnt/shareddrive type cifs (rw,relatime,vers=3.1.1,cache=strict,username=blorf,uid=0,noforceuid,gid=0,noforcegid,addr=192.168.1.20,file_mode=0755,dir_mode=0755,iocharset=utf8,soft,nounix,serverino,mapposix,rsize=4194304,wsize=4194304,bsize=1048576,echo_interval=60,actimeo=1,closetimeo=1)

Can I ask, do you just want the share mounted at boot, or do you want an autofs type of mount where it isn’t actually mounted until you connect to the mount ? I ask because that is what you seem to be trying to do.

So in principle I don’t need anything to be in place until I navigate to /mnt/shareddrive. If possible, I would like to do that in the most basic and portable way possible but obviously if I can’t r/w with my unprivileged user account it doesn’t really matter. Do you reckon I should look into autofs?

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.