@ChuckPa, I was reading your Linux tips article here and can’t wrap my head around the “Prepare the NAS” section. Why would you need to create the plex user in the Synology NAS? Doing so, more often than not the uid of the plex user in the Linux PMS has a different uid to that of the plex in the Synology NAS. So they’re technically different users when the two systems are involved. I also don’t see any “mapping” technique for NFS unless you use Kerberos. So how I have it setup in my environment is that when I set the mount point for the Synology shared folders, I do “map all users to admin” so that when the plex user in the Linux PMS runs whatever r/w processes against the NFS mount it still has the necessary permissions.
Why would I need to create a username on the Synology for access control permission management?
There are many reasons. The biggest reason, which is what I wrote the article to support, is maintaining separation of the different file owners on both Linux host and NFS server sides.
If you’re running everything as a single username on the either side, then my article means nothing.
I wrote the article to support a multi-user environment, namely:
Your username on the Linux host
User ‘plex’ on this same host
Possible use of other usernames on either the Linux host or Synology NAS.
Separation of privileges between what I can do as user “chuck” and and what Plex can do as user “plex”
This allows support of the two primary cases:
Case 1 - mount without use of sec=sys mount option.
The NFS open() call sends the username in ASCII.
The NFS server maps the relative path to absolute local path then maps the user name to local UID and checks access permisssion.
The user name is checked against the ACL to see if the requested permission is granted.
This is why the name is important. Synology uses names in their access permissions ACLs. This happens before we even get to the file system’s permission bits. If ACLs grant access, Synology’s nfsd honors it and completes the requested action.
Case 2 - mount using sec=sys mount option.
sec=sys is where UID-matching , or coupled with Kerberos-like functionality, works at the pure Linux level of the file system with the UID/GID assigned to the files & directories. The local Linux client does all access control checking and management. sec=sys is literally “security handled by local system”
My article
My help article assumes:
Basic Linux host
Bare Synology NAS (without Kerberos or LDAP service)
Single user workstation with my UID/GID
PMS server running on my workstation with plex's UID/GID
-and-
I want R/W access for myself
I want R/O for Plex
I want to administer file access control through the NAS (logical assumption)
Ok, forgive me as I’m a Linux noob but I do have a multi-user environment for both the Linux PMS and Synology NAS sides.
It seems that what I want is Case 1 where PMS’ plex user is mapped to the same plex user in the Synology NAS. You said that can be done without using sec=sys. Do you mean that I should explicitly specify sec=none? I know if you don’t specify this in your mount options, it defaults to sec=sys.
