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

[JWalsh]

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.

emby-server.service:

[Unit]
Description=Emby brings together your videos, music, photos, and live television
.
After=network.target

[Service]
User=emby
Group=media
SupplementaryGroups=render
SupplementaryGroups=video
DynamicUser=true
StateDirectory=emby
ReadWritePaths=-/dev/dri

EnvironmentFile=/etc/conf.d/emby-server
ExecStart=/usr/bin/emby-server
RestartForceExitStatus=3

AmbientCapabilities=
CapabilityBoundingSet=
LockPersonality=true
ProtectControlGroups=true
ProtectKernelModules=true
ProtectKernelTunables=true

[Install]
WantedBy=multi-user.target

[DeLinuxCo]

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.

[Aragorn]

@JWalsh

drwxrwsr-x 2 emby media 4096 Jun 11 07:48 temp

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…

[Tutorial] Understanding and working with UNIX filesystems and permissions

Difficulty: ★★★☆☆ Note: This post is meant as a tutorial. Please do not post on this thread regarding any problems you’re having with permissions, but start a new thread instead. Thank you. PREAMBLE: THE HISTORICAL BACKGROUND If you are new to the world of GNU/Linux ─ and especially if you come from the Microsoft Windows ecosystem ─ then you will undoubtedly have already noticed that GNU/Linux handles permissions and storage volumes quite differently from what you might be used to …

[JWalsh]

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

[Aragorn]

@JWalsh

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.

Then I apologize for misreading.

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

[xabbu]

@JWalsh

/home/media_files/

Is this the home of your emby user in passwd?

@JWalsh

DynamicUser=true

This implies a lot of extra security options. For example ProtectHome=read-only and ProtectSystem=strict
https://www.freedesktop.org/software/systemd/man/systemd.exec.html#DynamicUser=

---

Just checked ProtectHome=read-only, it means /home/, /root, and /run/user are read only.
https://www.freedesktop.org/software/systemd/man/systemd.exec.html#ProtectHome=

[JWalsh]

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.

[JWalsh]

@xabbu

@JWalsh

/home/media_files/

Is this the home of your emby user in passwd?

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

@xabbu

@JWalsh

DynamicUser=true

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

---

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

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.

[xabbu]

@JWalsh

I wondered asked about that, and was told it was because the emby user is dynamic.

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

[JWalsh]

@xabbu

@JWalsh

I wondered asked about that, and was told it was because the emby user is dynamic.

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

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?

[xabbu]

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.