Transmission Container not running as User & Group specified in config

Hello, all - I am working with a TrueNAS SCALE device. Prior to now, I was using the IX-provided container for Transmission without issue, but I recently decided I wanted a bit more control over my own setup, so I am in the process of moving my containers over to ones manage by Dockge instead.

When setting up Transmission under Dockge, I have specified the User & Group IDs as 568, but when the container runs, it’s running them as 911 as seen in the console. Am I missing something, or is this a bug?

Compose file:

services:
  transmission:
    image: lscr.io/linuxserver/transmission:latest
    container_name: transmission
    environment:
      - PUID=568
      - PGID=568
      - TZ=America/New_York
      - USER=(Redacted)
      - PASS=(Redacted)
    volumes:
      - /mnt/data/apps/transmission/config:/config
      - /mnt/data/torrents:/downloads
      - /mnt/data/torrents/watch:/watch
    ports:
      - 30096:9091
      - 51413:51413
      - 51413:51413/udp
    restart: unless-stopped

Console Output:

transmission has been recreated
transmission  | [migrations] started
transmission  | [migrations] no migrations found
transmission  | usermod: no changes
transmission  | ───────────────────────────────────────
transmission  | 
transmission  |       ██╗     ███████╗██╗ ██████╗
transmission  |       ██║     ██╔════╝██║██╔═══██╗
transmission  |       ██║     ███████╗██║██║   ██║
transmission  |       ██║     ╚════██║██║██║   ██║
transmission  |       ███████╗███████║██║╚██████╔╝
transmission  |       ╚══════╝╚══════╝╚═╝ ╚═════╝
transmission  | 
transmission  |    Brought to you by linuxserver.io
transmission  | ───────────────────────────────────────
transmission  | 
transmission  | To support LSIO projects visit:
transmission  | https://www.linuxserver.io/donate/
transmission  | 
transmission  | ───────────────────────────────────────
transmission  | GID/UID
transmission  | ───────────────────────────────────────
transmission  | 
transmission  | User UID:    911
transmission  | User GID:    911
transmission  | ───────────────────────────────────────
transmission  | Linuxserver.io version: 4.0.6-r0-ls268
transmission  | Build-date: 2024-11-19T10:41:19+00:00
transmission  | ───────────────────────────────────────
transmission  |     
transmission  | [custom-init] No custom files found, skipping...
transmission  | [2024-11-19 21:16:23.155] utils.cc:129: Couldn't read '/config/stats.json': Permission denied (13)
transmission  | [2024-11-19 21:16:23.157] utils.cc:129: Couldn't read '/config/bandwidth-groups.json': Permission denied (13)
transmission  | Connection to localhost (127.0.0.1) 30096 port [tcp/*] succeeded!
transmission  | [2024-11-19 21:16:24.162] ERR utils.cc:129 Couldn't read '/config/dht.dat': Permission denied (13) (utils.cc:129)
transmission  | [ls.io-init] done.
transmission  | s6-supervise svc-transmission: warning: finish script lifetime reached maximum value - sending it a SIGKILL
transmission  | Closing transmission session... done.
transmission exited with code 0

Someone else may chime in, but we don’t support dockge nor do we support truenas scale.

Nothing jumps out at me as wrong in your compose, though who knows what dockge is doing to that behind the scenes. We also assume your docker storage driver supports your house filesystem and that your not using remote mounts (which can work if setup correctly but isn’t something we support users with)

Thank you for the guidance.

I tried re-building the container using TrueNAS’ built in compose.yaml tool, and the same issue happened - I don’t think this is a Dockge issue. That being said, I’ll take this to the TrueNAS forums, and see if there’s something unique to that platform that may be causing an issue.

We do not support any “tool.” we support docker compose via a yaml file and docker compose X commands, or docker run from the command line. the only exception to this is unraid.

as you mention it could be a truenas issue, we do not test on truenas and none of us use it, so that very well could be. With that said, I have NEVER seen a docker ui that doesnt cause issues.