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 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Nux3LCu4zP9nih4BRhPyHw

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:-<command>}" >&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 "$@" ;;

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)