Permissions look right, but Emby says it can't write to directory

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.

But that’s a directory inside your $HOME. Does the process have read and execute/traverse access to your $HOME?

If it’s only a temporary directory for caching and it’s a system service rather than a user service, then why not use /var/tmp, which has drwxrwxrwt permissions?

Perhaps some explanatory reading… :arrow_down:

1 Like

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/.

Then I apologize for misreading. :bowing_man:

/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.


Is this the home of your emby user in passwd?

This implies a lot of extra security options. For example ProtectHome=read-only and ProtectSystem=strict

Just checked ProtectHome=read-only, it means /home/, /root, and /run/user are read only.


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. :slight_smile:

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. :slight_smile:

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. :smiley:

There’s no emby user in passwd. I wondered asked about that, and was told it was because the emby user is dynamic. :man_shrugging:

Aha! Thank you. That explains it perfectly.

Sounds like my options are to either make emby a regular user (not dynamic) or to move the media files elsewhere.

1 Like

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.

1 Like

Aha! If I understand correctly, my best move is to place the media files in /media_files instead of /home/media_files, then make sure /media_files/ (and everything under it) is owned by root:media.

Or am I still missing something? :slight_smile:

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.

1 Like

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