The permissions look right for the temp directory below, but when I tell Emby to use it as its server cache path it says, “Emby Server requires write access to this folder. Please ensure write access and try again.”
drwxrwsr-x 2 emby media 4096 Jun 11 07:48 temp
The Emby service runs with user emby and group media, so I’m puzzled as to why Emby can’t write to the temp directory.
Description=Emby brings together your videos, music, photos, and live television
I use Jellyfin but I think this is the same issue I had last year… Even though the emby service has it’s own user, it must have permissions to the directory as other users. So if you have another user on the server, try adding the emby user to that users group. I think that is how I solved it.
Interesting. What gave you the impression it was a directory inside of my $HOME? It’s actually under /home/media_files/ to which emby:media has the same permissions as above. My $HOME is /home/jwalsh/.
/home is either way not the place for data belonging to a system-wide service, and certainly not for temporary data. That’s what /tmp and /var/tmp are for, with the distinction that nothing must expect the data in /tmp to survive between reboots, while data in /var/tmp may be stored for longer.
I appreciate it, Aragorn. The fact is that I’m being a bit misleading. I was trying to simplify both for testing purposes and for the sake of posting an unambiguous question. That was my intention anyway.
The true situation is that I have the media files in /home/media_files, which I thought would be OK for that purpose. It certainly works when it comes to reading; Emby’s able to serve up the media just fine.
But when I ask Emby to save anything in those locations (such as media file conversions), it isn’t doing so. As I look at the log files I’m not seeing a lot of detail as to why (probably due to my lack of familiarity with the software).
As part of tracking down the source of the issue, I decided to temporarily direct Emby’s temp files to a folder in that structure to see if that would result in clearer feedback. And indeed, it did, as mentioned above.
So, I have no intention of using that directory for temp files on a permanent basis, so any concerns about that can be set aside.
The problem I really want to solve is that Emby isn’t able to write to the folders to which it appears to have very clear permission.
If the problem is that putting it in /home/ was a bad choice on my part, I’m happy to move the media files to a better location.
Yes it is dynamic unless it is set up as a regular user/groups with static IDs. This user and group is created at every start of this systemd services. Which means setting it on a folder is pointless, since the ID can change. It often doesn’t but it is not guaranteed. The name is never saved to a file if you use chown ... for example, it is just the ID.
At any point in time each UID/GID from this range is only assigned to zero or one dynamically allocated users/groups in use. However, UID/GIDs are recycled after a unit is terminated. Care should be taken that any processes running as part of a unit for which dynamic users/groups are enabled do not leave files or directories owned by these users/groups around, as a different unit might get the same UID/GID assigned later on, and thus gain access to these files or directories. systemd.exec
Exactly, it doesn’t need to be root, any static user is possible. Just make sure the group has the read/write for the folder(s) and read and maybe write permissions for the files. This is important. Sometimes just the user has write permissions.
In the other thread was an example drop-in file for the media group as an extra SupplementaryGroups and a path with read and wirte permissions. You would need to adapt the path but it is basically what you need to do.