Permission questions

Linux Distributions Ubuntu
1

I’m trying to learn Ubuntu. I’ve been using TrueNAS core and could use some help understanding some concepts.

My media is on TrueNAS with a user:group of media:media. All my .arr programs run as media so the can read and write to the media dir.

I installed Proxmox /Ubuntu VM on a spare computer and used a cifs share on TrueNAS to access the media. The media folder on Ubuntu shows root as user.

  1. Is that a function my TrueNAS cifs setup or something with the Ubuntu cifs client.
  2. I installed plex on Ubuntu which has the user plex and to my surprise it was able to read the media folder. Can some explain why that works? I would think the media would need to be plex user.

Thanks

2

If you’re using CIFS to mount the remote fs, you’ll want to give the login user and group as part of the mount command. For security,. you’d put the info in your ~/.smbcreds file and reference that from your mount command in /etc/fstab.

So in /etc/fstab:

> //myserver.local/work /work cifs vers=2.1,credentials=/home/myuser/.smbcreds,uid=5001,gid=6000,iocharset=utf8,rw,file_mode=0660,dir_mode=0770

And in your ~myuser/.smbcreds:

username=myuser
password=mypassword
workgroup=MYWORKGROUP

Then make sure the file has owner and group of root, and permissions are read-write for owner and read-only for group:

$ l ~myuser/.smbcreds
-rw-r----- 1 root root 58 Feb 28 2021 /home/myuser/.smbcreds

2 Likes
3

When you mount a CIFS folder, the permissions get masked by the user created in the SMB server.

So, let’s say you have the Samba server on TrueNAS Core running under the user media. You then connect on Ubuntu from the linux root user, using the SMB user media, to the CIFS share. On the mount point, i.e. in Ubuntu, you will see ownership as root, but in the backend, on TrueNAS, it will still be the user media.

If you unmount the CIFS from Ubuntu and mount it on the same Ubuntu box, but under a different user, like say pi, using the same credentials (media), the ownership of the files in the CIFS mount will now appear as pi, instead of root, but in the backend, the owner is still media on TrueNAS.

This is the opposite of NFS mounts, where the ownership uid:gid stays the same on both the client and the server. This makes Samba quite nice and not have to worry about a lot of stuff, despite it being a bit of a bigger and more (network) talkative piece of software. On NFS, I have to use the same UID and GID when creating users, because if I would have a user with UID 1000 on Ubuntu, say foo, and creating a file on a NFS share, on the NFS server, I’d either see ownership as 1000 if there is no user with that UID, or I’d see, say, bar, as the owner, but the UID is the same for both of them.

Yeah, SMB just masks the ownership on the backend, so as long as you use the same SMB user to login to the TrueNAS Core server, you won’t see permission issues.

1 Like
4

So just the clarify so I completely understand.

  1. My CIFS shows up as root:root because the mount was performed from the /etc/fstab while logged in as the root user.
  2. Plex can access the CIFS share as user plex as the CIFS share doesn’t care what the user:group is. That doesn’t sound very secure.
5

Assuming you are talking about the Ubuntu box, that is correct. The file on the CIFS mount on the Ubuntu box shows as root:root. The same files on the TrueNAS Core server show up as media:media (or whatever the username you created to connect to the Samba server is).

Wrong. Assuming it’s the same Ubuntu install. If you mount it as root and the group ownership is root, then the Plex user will still view the files on the Ubuntu box as having root:root ownership. If plex user creates new files (assuming the Other group has write permissions, so something like 777 or 776), then the new files over on the Ubuntu box will appear as owned by plex, but on TrueNAS core, they will still show up as media:media.

But if you unmount and remount the CIFS share, everything will change back to the local Linux user you mount the CIFS share as, so all the plex user’s files will be shown as root:root on Ubuntu, but still be media:media on TrueNAS. I am assuming that Plex can read the files over on the CIFS mount because the local mount permission for O group is set to read-permissible (774 / 776 / 777).

The CIFS client will mount a SMB share using a local user, be it root or something else, but the SMB server will convert whatever UID and GID that the client is seeing, to the UID and GID of the SMB user local to the server.

So the files on the server are always secure, as long as you don’t share your SMB account and password with other people. On the Ubuntu server however, the mount itself is only as secure as you make it to be. I would personally mount the CIFS share under the user running the Plex server, and if write permissions are not needed, I would just set the mount options to 400 (read-only for plex) or 500 (read and execute only for plex) if it needs exec rights (not likely for video and images).

6

The directories and files are actually 755

As plex only has to read the files is there any reason not to leave it as the current root:root?

7

Well, in the example I put, the uid and gid set in your fstab would be the uid and gid of the user whose credentials you’re using to log into the CIFS server. The filesystem will be mounted with those uid and gid and the permissions you set as well.

It’s why we set our primary group to be our household group and set the shares and mounts up with group write enabled.

We dont share or mount any with root:root, though.

2 Likes
8

Yeah, the example Buffy has given mounts the CIFS locally for the user who has the UID 5001 and the GID 6000, with file mode 660 (rw-rw----) and dir mode 770 (rwxrwx—).

The mount seems about right, besides mentioning a version. I just enforce a minimum version from the server side and let the client negociate if it wants SMB 2, 2.1 or 3.

I would go above and beyond with the .smbcreds file and set permissions to 600 instead of 640. Also, the file ownership should be myuser:myuser, not root:root (root can read it anyway).

1 Like