Using seerr docker with a custom defined user

[ioctl2]

Is it possible to run Seerr with a custom defined user in docker rather than the default hardcoded one? This was possible with Jellyseerr.

[fallenbagel]

Jellyseerr image ran rootfull and was not properly setup. Seerr is rootless now and the UID:GID 1000:1000 is the node user.
Here is why this is recommended (from a discussion in discord by @M0NsTeRRR)

Docker container does not works like that you should read some documentation on how permissions works, you can manage the issue you mention
https://docs.docker.com/engine/security/userns-remap/

The remapping itself is handled by two files: /etc/subuid and /etc/subgid. Each file works the same, but one is concerned with the user ID range, and the other with the group ID range. Consider the following entry in /etc/subuid:

testuser:231072:65536

This means that testuser is assigned a subordinate user ID range of 231072 and the next 65536 integers in sequence. UID 231072 is mapped within the namespace (within the container, in this case) as UID 0 (root). UID 231073 is mapped as UID 1, and so forth. If a process attempts to escalate privilege outside of the namespace, the process is running as an unprivileged high-number UID on the host, which does not even map to a real user. This means the process has no privileges on the host system at all.

And by RROX on discord:

The stanza that uses PUID/PGID requires the container to run as root. While this method lowers the permissions for the running application, the container still runs as root.

Setting a user in the dockerfile ensures the container is not spawned as root. For some sane languages, one can override the user with --user, but because node_modules, its not really feasible for a node image.

[glarizza]

So what do you recommend for the people who have a dedicated (and intentionally limited) docker user whose UID/GID is standard across all the VMs and who have permissions configured correctly on shared volume storage that use that specific UID/GID combination? I don't always run overseerr on the same VM, the UID/GID combination of 1000 is intentionally not used anywhere in my environment, and plumbing permissions just for one container that decides they want to use 1000:1000 is very....let's say "limiting."

There needs to be a way for power users to be able to provide the UID/GID for the user that accesses /app/config. You're basically punishing people who know what they're doing in favor of standardizing on your own magic UID/GID combination.

[M0NsTeRRR]

The user 1000:1000 does not need to exist on your host machine, so there’s no need to create it. Our documentation recommends a straightforward configuration for seerr, but the USER directive is ultimately a user-specific setting. You can use any UID/PUID you prefer just ensure you update file permissions accordingly.

We intentionally avoid covering advanced customizations like this in our documentation, as we prioritize simplicity (because many of our users do not have the knowledge and that's okay). If you want to customize this further, we recommend referring to Docker’s official documentation to fully understand how the USER directive works. I run myself Seerr with 2000:2000 and it works perfectly.

[mathisgauthey]

So using user: ${JELLYSEERR_UID}:${JELLYSEERR_GID} with our own specific user is possible and recommended as long as the directory mounted on /app/config is properly owned. Thanks for the insights and clarifications.

[DarkSpectrum]

Sorry to hijack the thread, @M0NsTeRRR I'm hoping you can help me with a related issue.

I'm migrating from jellyseerr to seerr using the instructions here

I'm using docker through Portainer on a Synology NAS. I understand there have been changes to a rootless user. When I start the container, I get this error:

Node.js v22.22.0
seerr@3.0.1 start
NODE_ENV=production node dist/index.js
2026-02-19T11:40:00.099Z [info]: Commit Tag: 789bcc8
2026-02-19T11:40:01.053Z [info]: Starting Seerr version 3.0.1
node:events:497
throw er; // Unhandled 'error' event
^
Error: EACCES: permission denied, open '/app/config/logs/seerr-2026-02-19.log'
Emitted 'error' event at:
at WriteStream. (/app/node_modules/.pnpm/file-stream-rotator@0.6.1/node_modules/file-stream-rotator/FileStreamRotator.js:697:15)
at WriteStream.emit (node:events:519:28)
at emitErrorNT (node:internal/streams/destroy:170:8)
at emitErrorCloseNT (node:internal/streams/destroy:129:3)
at process.processTicksAndRejections (node:internal/process/task_queues:90:21) {
errno: -13,
code: 'EACCES',
syscall: 'open',
path: '/app/config/logs/seerr-2026-02-19.log'
}

When I try to access the console, portainer says:
Unable to create exec: Container e690..... is restarting, wait until the container is running

Here is my Docker Compose:

services:
seerr:
image: ghcr.io/seerr-team/seerr:latest
init: true
container_name: seerr
environment:
- LOG_LEVEL=debug
- Australia/Perth
ports:
- 5056:5055
volumes:
- /volume1/docker/seerr:/app/config:rw
healthcheck:
test: wget --no-verbose --tries=1 --spider http://localhost:5055/api/v1/status || exit 1
start_period: 20s
timeout: 3s
interval: 15s
retries: 3
restart: unless-stopped`

I'm not sure what I need to do resolve the permissions for the node user.

[M0NsTeRRR]

Hello,

You must do this and it should fix your issue
https://docs.seerr.dev/migration-guide#config-folder-permissions

[DarkSpectrum]

Thank you, I saw this in the docs but where do I enter that command?

I'm unable to access the terminal for the seerr container because its constantly trying to start and restart due to the errors.

[fallenbagel]

Thank you, I saw this in the docs but where do I enter that command?

I'm unable to access the terminal for the seerr container because its constantly trying to start and restart due to the errors.

You will need to run it in a host shell. Not inside the container shell

[Zhoardkell]

Is it possible to run Seerr with a custom defined user in docker rather than the default hardcoded one? This was possible with Jellyseerr.

Looks like its posible using the user parameter.
https://docs.docker.com/reference/compose-file/services/#user

  seerr:
    image: ghcr.io/seerr-team/seerr:latest
    init: true
    container_name: seerr
    user: 13011:13000
    environment:
      - LOG_LEVEL=debug
#      - PUID=13011
#      - PGID=13000
      - UMASK=002
      - TZ=Europe/Amsterdam
#      - PORT=5055 #optional
    ports:
      - 5056:5055
    volumes:
      - ./config/seerr-config:/app/config
    healthcheck:
      test: wget --no-verbose --tries=1 --spider http://localhost:5055/api/v1/status || exit 1
      start_period: 20s
      timeout: 3s
      interval: 15s
      retries: 3
    restart: unless-stopped

[M0NsTeRRR]

You can go ahead, but as I mentioned in my other comments, using --userns-remap makes this approach rather pointless. If you still want to proceed, just make sure to update the permissions for your new user. We don’t want to officially support this scenario in our docs due to potential issues with permission management.

[DarkSpectrum]

After logging into the NAS via SSH and the entering the following command, it worked:

docker run --rm -v /path/to/appdata/config:/data alpine chown -R 1000:1000 /data

In my case the folder path was:

docker run --rm -v /volume1/docker/seerr:/data alpine chown -R 1000:1000 /data

[gspetrou]

I already had a user/group on my system using ID 1000, so I migrated that user to another ID (what a pain).

Using Docker it looks like I have to do the following in order to get the volume to be accessible to Seerr.

• Run the container once
• Shut it down
• Run sudo chmod -R a=,a+rX,u+w,g+w ./volume/where/config/is && sudo chown -R 1000:1000 ./volume/where/config/is
• Run the container again

Only then does Seerr get proper access to the config folder.

---

Could I be doing something wrong or is this actually more simple than letting us specify PUID/PGID?

[Zhoardkell]

My apologies, I completely misunderstood your meaning in almost this entire thread. In terms of migrating, if we just leave our docker-compose.yml with our current user/uid/gid, our existing custom user whose permissions are already set and working, it all works fine. Your example for docker cli says as much, it just doesnt have the same message for compose. Thank you for all your info and making Seerrr work so well.

Your current user/uid/gid is already used on most linux systems not running as root only.

By default, Most Linux systems automatically assign UIDs and GIDs to new user accounts in numerical order starting at 1000. In other words, if you create a user account during installation, it will have UID = 1000 and GID = 1000.

And i prefer not to run Seerr as that user.

[Ayitaka]

I agree. Sorry, once I finally found the single example, in the installation docker cli example, of using an existing u/gid I deleted my original message calling the setup/migration process of this project "insane", and as such my apology you are replying to might not make sense in its current context.

Unless you are, for some strange, insecure reason using root to login and use the system, 1000 should be the user you use to initially login and use the system/vm. Ideally, but obviously not necessarily, your login user should be different from the user used for all your plex stuff and the custom user would not have login privileges. This is so common now a days that most projects have it as part of the setup process, and examples generally show this format. I have honestly never come across a project that uses U/GID 1000 as their default u/gid for docker volumes. Enough people have questioned it that it should be obvious it is a questionably unique setup.

[fallenbagel]

1000:1000 has nothing to do with your user. It is for the node user inside the node Image. We have a blog post incoming that explains how it works.

[Zhoardkell]

1000:1000 has nothing to do with your user. It is for the node user inside the node Image. We have a blog post incoming that explains how it works.

I still prefer to know what its mapping to instead off having user namespace remapping automatically mapping it so some unkown high system uid:gid.

[fallenbagel]

1000:1000 has nothing to do with your user. It is for the node user inside the node Image. We have a blog post incoming that explains how it works.

I still prefer to know what its mapping to instead off having user namespace remapping automatically mapping it so some unkown high system uid:gid.

Wait for our blog post that explains the rationale and alternatives.