From 7f6b76ec12e8684392e2b40ce5cb7e9922bd7490 Mon Sep 17 00:00:00 2001 From: Lukas Remis Date: Mon, 14 Sep 2026 19:29:22 +0200 Subject: [PATCH] Deploy: explain the root-owned env file instead of leaking "Permission denied" init runs as root on a NAS, so docker/.env.prod is mode 600 owned by root and the data directories are root-owned. Running any subcommand as a normal user produced a bare redirect error naming an internal line number, with no hint about the cause. require_env now checks readability first and says who you are running as, the exact sudo command to repeat, and that `sudo -i` avoids it for the session. Docs note it beside the show-key step and above the command reference. Reproduced with a root-owned 600 env file read as a normal user; the message is what that case now prints. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01Nux3LCu4zP9nih4BRhPyHw --- deploy/webmail.sh | 11 +++++++++++ docs/nas-install.md | 13 +++++++++++-- 2 files changed, 22 insertions(+), 2 deletions(-) diff --git a/deploy/webmail.sh b/deploy/webmail.sh index 8b7ab5e..147217a 100755 --- a/deploy/webmail.sh +++ b/deploy/webmail.sh @@ -59,6 +59,16 @@ load_env_file() { require_env() { [ -f "$ENV_FILE" ] || die "$ENV_FILE not found. Run: ./deploy/webmail.sh init" + # The env file is chmod 600 and usually owned by root (init is run as root + # on a NAS), and the data directories are root-owned too. Say so plainly + # instead of letting a bare "Permission denied" escape from a redirect. + if [ ! -r "$ENV_FILE" ]; then + red "error: cannot read $ENV_FILE (it holds the master key, so it is chmod 600)." >&2 + red "You are running as $(id -un). Re-run this with sudo:" >&2 + red " sudo $0 ${SUBCOMMAND:-}" >&2 + red "Or start a root shell for the session: sudo -i" >&2 + exit 1 + fi load_env_file "$ENV_FILE" [ -n "${DATA_ROOT:-}" ] || die "DATA_ROOT is not set in $ENV_FILE" [ -n "${MASTER_KEY:-}" ] || die "MASTER_KEY is not set in $ENV_FILE" @@ -434,6 +444,7 @@ cmd_shell() { require_env; compose exec "${1:-api}" /bin/sh; } usage() { awk 'NR>1 { if ($0 ~ /^#/) { sub(/^# ?/, ""); print } else exit }' "${BASH_SOURCE[0]}"; } cmd="${1:-}"; shift || true +SUBCOMMAND="$cmd" case "$cmd" in init) cmd_init "$@" ;; doctor) cmd_doctor "$@" ;; diff --git a/docs/nas-install.md b/docs/nas-install.md index bb0e5bb..0ff0230 100644 --- a/docs/nas-install.md +++ b/docs/nas-install.md @@ -144,7 +144,12 @@ bash deploy/webmail.sh show-key > /volume1/docker/webmail/MASTER_KEY.txt ``` Run it, open `MASTER_KEY.txt` in File Station, copy the key into your password -manager, then **delete the file**. Skipping this is the one mistake with no +manager, then **delete the file**. + +> Doing this from an SSH shell instead? `init` created that file as root with +> mode 600, so run it as root or you get "Permission denied": +> `sudo bash deploy/webmail.sh show-key`. The same goes for every other command +> here — the data directories are root-owned, so start with `sudo -i`. Skipping this is the one mistake with no recovery: without that key, no backup can decrypt your saved mail-account passwords. @@ -415,8 +420,12 @@ per container, so they can't fill the volume. ## 9. Command reference +Run these as root (`sudo -i` first): the env file is mode 600 and the data +directories are root-owned. + ``` -./deploy/webmail.sh init create data dirs + generate secrets +./deploy/webmail.sh init [flags] create data dirs + generate secrets +./deploy/webmail.sh show-key print MASTER_KEY so you can back it up ./deploy/webmail.sh doctor pre-flight checks ./deploy/webmail.sh up [--meili] start everything ./deploy/webmail.sh down stop (data untouched)