Only allow files created by Emby to be deleted

[gene0915 37]

A while back, I made a post about Emby failing to create metadata inside the folder where the media was at vs. storing it in some internal database. It was configured to do so but just wasn't doing it. Turns out (duh), Emby didn't have write permission to any of my media folders. (There was that bug a while back where Emby would delete an entire folders' contents if the media wasn't stored in sub-directories and you told Emby to delete a single item.) I believe that bug was fixed but like Plex, I don't give Emby write access to my media out of fear of bugs or somebody hacking into my Plex/Emby account and deleting things.

 

So, I was doing some Googling and stumbled upon maybe a solution. What if I use the sticky bit and do something like this to my /mnt/Movies/ folder:

chmod o+t directory

Right now, Emby has read/execute access to my movies directory.... if I issues that command above, will that allow Emby to write into that folder (and all sub-folders) and allow it to only delete files (metadata in this case) that it created and nothing else?

 

I'm a bit of a Linux newbie and don't want to do something that could potentially wreck my system so that's why I want to ask first.

Edited May 10, 2020 by gene0915

[Luke 37358]

Hi, in theory it's possible, but why not try it on a test library?

[mastrmind11 717]

the emby user is the one that creates the metadata.  check out the file permissions of a metadata file, it'll be emby:emby unless you messed with permissions already.  so simply create a group with read only access, stick emby in it, and assign it to your media files only.  now you can do what you want with the media files and emby can't touch them, but can still manage metadata since emby is the author.

[gene0915 37]

the emby user is the one that creates the metadata.  check out the file permissions of a metadata file, it'll be emby:emby unless you messed with permissions already.  so simply create a group with read only access, stick emby in it, and assign it to your media files only.  now you can do what you want with the media files and emby can't touch them, but can still manage metadata since emby is the author.

 

Since I'm super ultra paranoid about damaging my main Linux install, I spun up a virtual Linux box and installed Emby in there and created a group called 'embymeta' and added the emby user to that group. It appears that Emby can access that folder but can't write to it. I did some Googling and can't find the proper commands to allow users that are part of the 'embymeta' group the ability to create metadata in the individual movie folders while denying them write access to the main mkv/mp4 movies files.

 

When you say, "assign it to your media files only".... I'm not following you there. I've learned a LOT about Linux over the past couple of years of using it but I still consider myself a total newbie so forgive me if I can't see the forest for the trees.

[mastrmind11 717]

Since I'm super ultra paranoid about damaging my main Linux install, I spun up a virtual Linux box and installed Emby in there and created a group called 'embymeta' and added the emby user to that group. It appears that Emby can access that folder but can't write to it. I did some Googling and can't find the proper commands to allow users that are part of the 'embymeta' group the ability to create metadata in the individual movie folders while denying them write access to the main mkv/mp4 movies files.

 

When you say, "assign it to your media files only".... I'm not following you there. I've learned a LOT about Linux over the past couple of years of using it but I still consider myself a total newbie so forgive me if I can't see the forest for the trees.

no worries.  you have to chmod the individual media files to be read only once they're in the folder.

[Q-Droid 673]

Creating and deleting files are directory level operations and where such permissions need to be allowed or denied. Reads and updates to existing files obey the file level permissions. Keep this in mind when working out your access schemes.