DMS 7.1: Delete not working when Plex is running in a Docker container

Hmmm… some experimentation has yielded additional questions. As I said I don’t like having a non-executable files listed as executable (777). From Earth (remember, Jupiter = Synology and Earth = Ubuntu Desktop), over NFS, a chmod(1) strips the ACLs:

Jupiter:touch /Videos/file
Jupiter:ll /Videos/file
-rwxrwxrwx+ 1 andrew defaria 0 May 28 10:31 /Videos/file*
Jupiter:

Now chmod it from Earth:

Earth:chmod 644 /Videos/file 
Earth:ll /Videos/file
-rw-r--r-- 1 andrew defaria 0 May 28 10:33 /Videos/file
Earth:

Even Jupiter sees the file with the ACLs stripped:

Jupiter:ll /Videos/file 
-rw-r--r-- 1 andrew defaria 0 May 28 10:33 /Videos/file
Jupiter:

And even if I recreate /Videos/file from Jupiter and use the chmod(1) command to change the permissions, it still strips off the ACLs:

Jupiter:rm /Videos/file
Jupiter:touch /Videos/file
Jupiter:ll /Videos/file
-rwxrwxrwx+ 1 andrew defaria 0 May 28 10:36 /Videos/file*
Jupiter:chmod 644 /Videos/file
Jupiter:ll /Videos/file
-rw-r--r-- 1 andrew defaria 0 May 28 10:36 /Videos/file
Jupiter:

Do I have to tolerate non-executable files to be executable in order for the ACLs to remain and for the Plex web page to be able to delete files?

Further experimentation yields the following:

Jupiter:mkdir /Videos/dir
Jupiter:ll -d /Videos/dir
drwxrwxrwx+ 1 andrew defaria 0 May 28 10:50 /Videos/dir/
Jupiter:touch /Videos/dir/file
Jupiter:ll /Videos/dir/file
-rwxrwxrwx+ 1 andrew defaria 0 May 28 10:50 /Videos/dir/file*
Jupiter:chmod 644 /Videos/dir/file
Jupiter:ll /Videos/dir/file
-rw-r--r-- 1 andrew defaria 0 May 28 10:52 /Videos/dir/file
Jupiter:docker exec -u 297536 -it plex bash
plex@Jupiter:/$ ls -ld /Videos/dir
drwxrwxrwx 1 1000 1000 8 May 28 10:52 /Videos/dir
plex@Jupiter:/$ ls -ld /Videos/dir/file
-rw-r--r-- 1 1000 1000 0 May 28 10:52 /Videos/dir/file
plex@Jupiter:/$ rm /Videos/dir/file
rm: remove write-protected regular empty file '/Videos/dir/file'? y
plex@Jupiter:/$ 

So I can find /Videos/ -type f -exec chmod 644 {} + to remove execute permission on files only while leaving the directories untouched and thus with their ACLs intact. The plex user in the Docker container is able to remove such files. I’m not sure if this is a good way to handle this.

Also I have been using ffmpeg to convert my files to HEVC form where they are smaller. I’m doing this from Earth because it has the GPUs that make this transcoding process fast. I then move the converted videos back in place. When doing this the ACLs are lost.

So is leaving the ACLs on the directories only a good way to allow the Plex web app to be able to conveniently delete videos?

Note also that while an ll from Jupiter shows the ‘+’ indicating ACLs, it doesn’t from inside the container. I find that confusing.

I also don’t know of a way to manipulate ACLs on the Synology via the command line, just from that GUI.

Thoughts?

You’re doing well :slight_smile:

Any chmod will trip synoacls ← key point.

Here is how to restore (what filestation does)

chuck@ds418:/volume1/Animated/Your Friend the Rat (2007)$ synoacltool -get stuff 
ACL version: 1 
Archive: is_inherit,is_support_ACL 
Owner: [chuck(user)] 
--------------------- 
	 [0] user:PlexMediaServer:allow:rwxpdDaARWc--:---- (level:2)
	 [1] user:chuck:allow:rwxpdDaARWcCo:---- (level:2)
	 [2] user:demo:allow:r-x---a-R-c--:---- (level:2)
	 [3] user:chuck:allow:rwxpdDaARWc--:---- (level:2)
	 [4] user:admin:allow:rwxpdDaARWc--:---- (level:2)
chuck@ds418:/volume1/Animated/Your Friend the Rat (2007)$ chmod 666 stuff
chuck@ds418:/volume1/Animated/Your Friend the Rat (2007)$ synoacltool -get stuff 
(synoacltool.c, 489)It's Linux mode
chuck@ds418:/volume1/Animated/Your Friend the Rat (2007)$ ls -la stuff
-rw-rw-rw- 1 chuck root 0 Jun 25  2020 stuff
chuck@ds418:/volume1/Animated/Your Friend the Rat (2007)$ chmod 666 stuff
chuck@ds418:/volume1/Animated/Your Friend the Rat (2007)$ synoacltool -add stuff user:PlexMediaServer:allow:rwxpdDaARWCc:fd--
ACL version: 1 
Archive: has_ACL,is_support_ACL 
Owner: [chuck(user)] 
--------------------- 
	 [0] user:PlexMediaServer:allow:rwxpdDaARWcC-:fd-- (level:0)
chuck@ds418:/volume1/Animated/Your Friend the Rat (2007)$ 

Linux has getfacl and setfacl . Synology doesn’t acknowledge them.

After doing this I see:

Jupiter:ll stuff
----------+ 1 andrew defaria 0 May 28 20:07 stuff
Jupiter:

IOW it strips of the 666. I guess I’m looking for:

rw-r--r---+ 1 andrew defaria 0 May 28 20:10 stuff

That’s correct behavior.

That’s why FileStation adds the permissions for your username (the owner) and the ACL.

They’ve made a seriously complicated mess.

There IS a work around but it means modifying /etc/group on the Syno.
It will break synology’s rules but it’s your machine.

If they see it, they will cry foul and not support the machine until DSM is reinstalled.

I have long since violated Synology’s “rules”. They have yet to see my machine.

It seems they’ve implemented a lot of new “stuff” over regular old Unix (and Linux, I started with Unix). Perhaps for well-intentioned reasons. I may just say screw it and chmod stuff back to me and forget about the convenient delete in the Plex Web App.

Actually …

you can go Linux mode and chmod everything… BUT

( … in for a penny - in for a pound … )

Add PlexMediaServer to your group … which is users, gid=100 :slight_smile: Break it good LOL

Watch as problems magically fall away.

I started with Unix in 1983. Switched to Linux in 1999

Actually my group is “1000:defaria”. Makes the ls -l come out as owned by andrew in the group defaria (my last name). So I did this:

Jupiter:grep 1000 /etc/group
defaria:x:1000:plex,PlexMediaServer
Jupiter:

Had the user “plex” in my group for a while. That’s probably when it used to work. I think DSM introduced the PlexMediaServer user and group. So it makes sense that I should add “PlexMediaServer” to my group “defaria”.

That will work too. As long as user PlexMediaServer:PlexMediaServer has the appropriate access rights , slice it any way you want.

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