The bind-mount permission fix only takes effect after a rebuild, so a
stale image keeps failing with the opaque "unable to open database file".
This hardens both sides so any remaining failure is self-explanatory:
- docker-entrypoint.sh: fall back to chmod 777 when chown is unsupported
(network/9p mounts), and fall back to running as root when su-exec is
unavailable, so the data dir is always writable on any filesystem.
- server/db.mjs: wrap the DatabaseSync open in a try/catch and, on
failure, report the exact path, whether the directory is writable, and
the process UID instead of the bare SQLite error.
Verified with a real container: a normal bind mount serves /health and
creates trxtd.db; a read-only mount now prints the directory-permission
diagnostic instead of the raw SQLite error.
The container ran as the unprivileged "node" user, but bind-mounted host
directories (e.g. ./data:/app/data in docker-compose or an Unraid appdata
folder) are mounted with root ownership. The node user therefore could not
create trxtd.db in /app/data, failing at startup with:
Error: unable to open database file
at file:///app/server/db.mjs:12
Fix:
- Add docker-entrypoint.sh that mkdir/chown /app/data to node:node on
container start, then drops privileges back to node via su-exec
- Install su-exec in the runtime stage (apk add --no-cache su-exec)
- Remove USER node so the entrypoint runs as root and can fix ownership,
with privilege dropping handled inside the entrypoint instead
- Wire the script up as ENTRYPOINT, keeping CMD as the app itself
The mount path itself is unchanged (/app/data, host ./data). Verified with
a real bind mount: /health responds ok and trxtd.db/-shm/-wal are created
in the mounted directory.
