[BUG]Permission Denied Error When Writing to /app/data/.env During JWT Secret Initialization

[haiyinlin]

Title

Permission Denied Error When Writing to /app/data/.env During JWT Secret Initialization

Platform

Website - Chrome

Server Installation Method

Docker

Version

release-1.10.0

Troubleshooting

• I have examined logs and tried to find the issue
• I have reviewed opened and closed issues
• I have tried restarting the application
• I have read Known Issues (Known Issues (Read Before Posting) #296)

The Problem

Description:
When starting the container, the application fails to initialize the JWT secret due to a permission error when attempting to write to /app/data/.env. The error occurs in both Debian 12 and Unraid 7.1.4 environments.
[9:52:22 PM] [ERROR] [🗄️] Failed to initialize JWT secret [op:jwt_init_failed] Error: EACCES: permission denied, open '/app/data/.env' at async open (node:internal/fs/promises:641:25) at async Object.writeFile (node:internal/fs/promises:1215:14) at async SystemCrypto.updateEnvFile (file:///app/dist/backend/backend/utils/system-crypto.js:285:13) at async SystemCrypto.generateAndGuideUser (file:///app/dist/backend/backend/utils/system-crypto.js:184:9) at async SystemCrypto.initializeJWTSecret (file:///app/dist/backend/backend/utils/system-crypto.js:49:13) at async file:///app/dist/backend/backend/starter.js:76:9 { errno: -13, code: 'EACCES', syscall: 'open', path: '/app/data/.env' }

Environment:

Debian 12 (with Docker Compose)

Unraid 7.1.4

Workarounds Attempted:

Debian 12: Added user: "0:0" to docker-compose.yml to run container as root (high security risk).

Unraid 7.1.4: Set folder ownership to root (high security risk).

Root Cause Analysis:
The container's application (running as non-root user) lacks write permissions to the mounted volume /app/data. The .env file needs to be created/modified during JWT initialization, but the default container user cannot write to the mounted directory.

Security Concerns:
Current workarounds require running with elevated privileges or modifying permissions, which poses security risks. A more secure solution is needed.

How to Reproduce

services:
termix:
image: ghcr.io/lukegus/termix:latest
container_name: termix
restart: unless-stopped
ports:
- "8080:8080"
volumes:
- /usr/mydocker/termix/data:/app/data
environment:
PORT: "8080"
user: "0:0"
networks:
macnet:
ipv4_address: 192.168.xx.xx
ipv6_address: fdc7:xxxx:xxxx::20

networks:
test2:
external: true

Additional Context

No response

[MalibThalion]

I have this same issue. Also on unraid for some reason

[LukeGus]

Try updating to the latest version (v1.11.0 which just came out). Unraid may or may not be fixed, I don't manage that, nor have I ever used Unraid so that was done by a community member.

[MalibThalion]

Thanks, will give it a try. I'm using compose so I'm not relying on anyone in this case :)

[MalibThalion]

Unfortunately, its still the same permission issue. It's the first container for me that has internal permission issues

2026-01-25T08:35:33.572569905Z [8:35:33 AM] [ERROR] [🗄️] Failed to initialize JWT secret [op:jwt_init_failed]
2026-01-25T08:35:33.572669697Z Error: EACCES: permission denied, open '/app/data/.env'
2026-01-25T08:35:33.572703529Z     at async open (node:internal/fs/promises:636:25)
2026-01-25T08:35:33.572710418Z     at async Object.writeFile (node:internal/fs/promises:1205:14)
2026-01-25T08:35:33.572715929Z     at async SystemCrypto.updateEnvFile (file:///app/dist/backend/backend/utils/system-crypto.js:285:13)
2026-01-25T08:35:33.572721282Z     at async SystemCrypto.generateAndGuideUser (file:///app/dist/backend/backend/utils/system-crypto.js:184:9)
2026-01-25T08:35:33.572726571Z     at async SystemCrypto.initializeJWTSecret (file:///app/dist/backend/backend/utils/system-crypto.js:49:13)
2026-01-25T08:35:33.572731832Z     at async file:///app/dist/backend/backend/starter.js:76:9 {
2026-01-25T08:35:33.572737737Z   errno: -13,
2026-01-25T08:35:33.572743544Z   code: 'EACCES',
2026-01-25T08:35:33.572748616Z   syscall: 'open',
2026-01-25T08:35:33.572754418Z   path: '/app/data/.env'
2026-01-25T08:35:33.572759253Z }

[Jeanball]

Same on my side!

Just want to try out Termix and having issue to read .env stored in /app/data

[mellismike]

I just tried a brand new install on an ubuntu host, using docker compose. release-1.10.0 and 1.11.0 failed with the same error above. I rolled back to 1.9.0 and it worked and created the container correctly. The only thing I changed in my compose.yml from default in the docs was the volume. I like using a folder in my user folder, so I changed

    volumes:
      - termix-data:/app/data

volumes:
  termix-data:
    driver: local

to this:

    volumes:
      - ./data:/app/data

The above changed worked on 1.9.0 and failed on 1.10.0 and 1.11.0. Completely new install. I reverted back to termix-data:/app/data mapping and it worked on 1.11.0.

[d8sychain]

For those of you on Unraid, do the following, assuming you are using the default path
chown -R 1000:1000 /mnt/user/appdata/termix/data
chmod -R 755 /mnt/user/appdata/termix/data

Maybe the Devs can
Add apt-get install -y su-exec to Dockerfile
Remove USER node from Dockerfile
Add something like this to the top of entrypoint.sh

#!/bin/sh
set -e

# ============ PUID/PGID Support ============
PUID=${PUID:-1000}
PGID=${PGID:-1000}

if [ "$(id -u)" = "0" ]; then
    echo "Setting up user permissions (PUID: $PUID, PGID: $PGID)..."
    groupmod -o -g "$PGID" node 2>/dev/null || true
    usermod -o -u "$PUID" node 2>/dev/null || true
    
    # Ensure ownership of key directories
    chown -R node:node /app/data /app/uploads /app/nginx 2>/dev/null || true
    
    echo "User node is now UID: $PUID, GID: $PGID"
    
    # Re-execute this script as the modified user
    exec su-exec node:node "$0" "$@"
fi
# ============================================

# Rest of the current entrypoint continues unchanged...

Then users can pass their own UID and GID. For Unraid users, it would look something like this:

docker run -d \
  --name=termix \
  -e PUID=99 \
  -e PGID=100 \
  -v /path/to/data:/config \
  termix/image:tag

I have not looked into exactly how LinuxServer.io goes about doing it in their images, just that they do.
https://docs.linuxserver.io/general/understanding-puid-and-pgid/