Is there an existing issue for this?
Current Behavior
I've installed the latest version: v1.0.22-ls239 on Synology 7.2.2 72806 Update 4, but the install/container is not creating the system internal user: sc-medusa
As a result, I can't give Medusa R/W permission for shared folders
Expected Behavior
In all past versions, the container creates sc-medusa: the system internal user in the group: sc-downloads.
Steps To Reproduce
Environment
- OS: Synology 7.2.2 72806 Update 4
- How docker service was installed:
Container Manager, YML file
CPU architecture
x86-64
Docker creation
services:
medusa:
image: linuxserver/medusa:latest
container_name: medusa
environment:
- PUID=1026
- PGID=101
- TZ=America/Chicago
- UMASK=022
volumes:
- /volume1/docker/medusa:/config
- /volume1/data/torrents/completed:/downloads
- /volume1/TV:/tv
ports:
- 8081:8081/tcp
network_mode: synobridge
security_opt:
- no-new-privileges:true
restart: always
Container logs
2025/10/02 19:47:07 stdout [ls.io-init] done.
2025/10/02 19:47:07 stderr Connection to localhost (127.0.0.1) 8081 port [tcp/tproxy] succeeded!
2025/10/02 19:47:06 stderr 2025-10-02 19:47:06 INFO MAIN :: [] Building internal name cache for all shows
2025/10/02 19:47:06 stderr 2025-10-02 19:47:06 INFO MAIN :: [] Finished processing 5026 scene exceptions.
2025/10/02 19:47:06 stderr 2025-10-02 19:47:06 INFO MAIN :: [] Updating exception_cache and exception_season_cache
2025/10/02 19:47:06 stderr 2025-10-02 19:47:06 INFO TORNADO :: [] Starting Medusa on http://0.0.0.0:8081/
2025/10/02 19:47:06 stderr 2025-10-02 19:47:06 INFO MAIN :: [] Starting Medusa [master] using '/config/config.ini'
2025/10/02 19:46:58 stdout [custom-init] No custom files found, skipping...
2025/10/02 19:46:58 stdout
2025/10/02 19:46:58 stdout ───────────────────────────────────────
2025/10/02 19:46:58 stdout User GID: 101
2025/10/02 19:46:58 stdout User UID: 1026
2025/10/02 19:46:58 stdout
2025/10/02 19:46:58 stdout ───────────────────────────────────────
2025/10/02 19:46:58 stdout GID/UID
2025/10/02 19:46:58 stdout ───────────────────────────────────────
2025/10/02 19:46:58 stdout
2025/10/02 19:46:58 stdout https://www.linuxserver.io/donate/
2025/10/02 19:46:58 stdout To support LSIO projects visit:
2025/10/02 19:46:58 stdout
2025/10/02 19:46:58 stdout ───────────────────────────────────────
2025/10/02 19:46:58 stdout Brought to you by linuxserver.io
2025/10/02 19:46:58 stdout
2025/10/02 19:46:58 stdout ╚══════╝╚══════╝╚═╝ ╚═════╝
2025/10/02 19:46:58 stdout ███████╗███████║██║╚██████╔╝
2025/10/02 19:46:58 stdout ██║ ╚════██║██║██║ ██║
2025/10/02 19:46:58 stdout ██║ ███████╗██║██║ ██║
2025/10/02 19:46:58 stdout ██║ ██╔════╝██║██╔═══██╗
2025/10/02 19:46:58 stdout ██╗ ███████╗██╗ ██████╗
2025/10/02 19:46:58 stdout
2025/10/02 19:46:58 stdout ───────────────────────────────────────
2025/10/02 19:46:57 stdout [migrations] no migrations found
2025/10/02 19:46:57 stdout [migrations] started
Is there an existing issue for this?
Current Behavior
I've installed the latest version: v1.0.22-ls239 on Synology 7.2.2 72806 Update 4, but the install/container is not creating the system internal user: sc-medusa
As a result, I can't give Medusa R/W permission for shared folders
Expected Behavior
In all past versions, the container creates sc-medusa: the system internal user in the group: sc-downloads.
Steps To Reproduce
Environment
CPU architecture
x86-64
Docker creation
services: medusa: image: linuxserver/medusa:latest container_name: medusa environment: - PUID=1026 - PGID=101 - TZ=America/Chicago - UMASK=022 volumes: - /volume1/docker/medusa:/config - /volume1/data/torrents/completed:/downloads - /volume1/TV:/tv ports: - 8081:8081/tcp network_mode: synobridge security_opt: - no-new-privileges:true restart: alwaysContainer logs