Problem

After the fix for #1470 (PR #1635, released in v0.50.294), docker_init.bash crashes with:

!! ERROR: Cannot modify /etc/group or /etc/passwd (read-only root fs). Set UID=1024 and GID=1024 to match, or run without read_only=true. See issue #1470.
!! Exiting script (ID: 1)

This happens on standard Docker setups (not podman, no read_only=true flag).

Root Cause

The read-only guard at line 193 uses:

if [ ! -w /etc/group ] || [ ! -w /etc/passwd ]; then

This check runs as hermeswebuitoo (non-root, UID 1025). On a normal writable rootfs, /etc/group and /etc/passwd are owned by root — so the test always fails because a non-root user can't write there.

The actual groupmod/usermod commands (line 206-207) use sudo, so they would work fine on a writable rootfs.

In short: the check tests writability as the current user, but the modification happens via sudo. This is a false positive on every standard Docker setup where UID/GID don't match the image defaults (1025).

Reproduction

Standard docker-compose.yml:

services:
  hermes-webui:
    image: ghcr.io/nesquena/hermes-webui:latest
    environment:
      - UID=1000
      - GID=1000
    # ... standard setup, no read_only flag

Container enters restart loop immediately.

Fix

Check writability via sudo instead of as the current user:

if ! sudo sh -c 'test -w /etc/group && test -w /etc/passwd' 2>/dev/null; then
    _readonly_root=true
    ...
fi

This correctly distinguishes between:

• Normal writable rootfs → sudo can write → guard doesn't trigger → groupmod/usermod works
• Truly read-only rootfs (podman read_only=true) → sudo can't write either → guard triggers correctly

Environment

• Docker Engine (not podman)
• No read_only=true flag
• UID=1000 GID=1000 (host user, different from image default 1025)
• Image: ghcr.io/nesquena/hermes-webui:latest (v0.50.295+)