Force rest-server to write repository with an ID of a system user instead of root

I‘m using the ajoergensen/rest-server docker image on my Raspi and it works like a charm. The files in a repository created with this container is created with the root user.

My repository which I am currently using is created without rest-server as a user (UID 1000) with a local directory as backend. Now I would like to write to the repository via the rest-server docker container as well but I am afraid, that the server would write new files with UID 0 instead of UID 1000. I would suppose this would make problems when pruning files, wouldn‘t it?

Is there a possibility to force rest-server to write with a configurable UID?

Thanks, schmud

If the container runs as root, it will generally be able to read and write any other UID’s files, so it should be fine in that regard. But if your UID 1000 user then tries to use the repository which contains files owned by UID 0, it will of course fail to change or delete those files. So yes, better keep your file permissions in shape :slight_smile:

The fact that your container runs and writes files as UID 0 is simply because the rest-server process in that container runs as root/UID 0. You can run the container with any user you want, either by giving the --user <UID>[:<GID] option to docker run, or setting the user: option in your Docker Compose file, if you use that. Note that it’s up to how the container was created, whether this works out of the box. Sometimes the Docker image is designed in a way that does not support running the process as an unprivileged user out of the box. You’ll have to try it and see if you need to make adjustments.

Generally speaking, you should always strive for running docker containers as unprivileged users instead of root.

@rawtaz Thank you for the detailed explanations.
In fact the —user flag did the job. :+1:t2:
Unfortunately, the rsyslogd inside the container is also running with UID 1000 now, so it has got problems with permissions. But this seems to be another topic.

Cheers, schmud

That’s one thing to fix then. It’s very common to have these types of issues when tightening down an image that wasn’t made to be run as unprivileged user.

You’ll simply need to look at what directory or file(s) rsyslogd tries to write to, and add a tmpfs, bind mount, anonymous volume or named volume on those paths, accordingly. You can find all of those in the Docker and Docker Compose documentation.


The docker image supports environment variables PUID and PGID. Now everything seems to work as wanted. Thanks again for your support!

1 Like

Nice! So it was a well-behaved image after all :tada:

Just a quick update if it‘s for someone‘s interest.
The image I used ignores the PUID and PGID variables.
I decided to build my own docker image and start it with the proposed —user flag. This seems to work perfectly now.

1 Like