From 74628f373631d2f57158bdb001f46cfa6f84a8db Mon Sep 17 00:00:00 2001 From: Claude Date: Tue, 11 Aug 2026 03:22:53 +0000 Subject: [PATCH] Fix vaultwarden SMTP false-positive and mattermost DB password mismatch MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit vaultwarden: SMTP_PORT defaulted to "587" and SMTP_SECURITY was a hardcoded "starttls" literal in the .env template, written unconditionally regardless of whether SMTP_HOST was ever provided. Confirmed live: skipping SMTP entirely (blank SMTP_HOST) still wrote real values for those two, and Vaultwarden reads that as "some SMTP config is present," refusing to start ("Both SMTP_HOST and SMTP_FROM need to be set") even with host/from genuinely blank. Both now stay empty unless SMTP_HOST is actually set. mattermost: DB_PASS/MM_SECRET were only reused from the existing .env when MODE=update — a "fresh" reinstall always generated a new POSTGRES_PASSWORD. Confirmed live: choosing fresh after removing only the mattermost app container (not the whole directory) regenerates the password in .env while db/'s existing Postgres data still enforces the OLD one from its first init (the entrypoint skips re-init on existing data), causing "password authentication failed for user mattermost" on every start. Whether db/ already has real data is what actually determines whether the old password is still live, not which reinstall mode was chosen — reuse the existing secrets whenever db/ is non-empty, regardless of MODE. Co-Authored-By: Claude Sonnet 5 Claude-Session: https://claude.ai/code/session_01H4k6J1qXXyYxhGEgnJaMvn --- services/mattermost.sh | 21 +++++++++++++++------ services/vaultwarden.sh | 16 +++++++++++++--- 2 files changed, 28 insertions(+), 9 deletions(-) diff --git a/services/mattermost.sh b/services/mattermost.sh index a2347a2..224e887 100644 --- a/services/mattermost.sh +++ b/services/mattermost.sh @@ -322,13 +322,22 @@ install_mattermost() { ensure_docker_dir_ownership "$DIR" cd "$DIR" || return 1 - # Reuse existing secrets on update — Postgres's volume keeps the password - # from its first init, so overwriting .env with a fresh one locks - # Mattermost out of its own database. Confirmed this was previously - # unconditional (regenerated every single rerun, silently breaking the DB - # connection) — fixed here as part of adding proper update detection. + # Reuse existing secrets whenever the Postgres data volume already has + # real data in it — not just when MODE=update. Confirmed live: picking + # "fresh" after removing only the mattermost APP container (docker rm, + # not the whole ~/docker/mattermost directory) regenerates + # POSTGRES_PASSWORD in a new .env while db/ still holds the OLD + # password baked in from its first init (postgres:15-alpine's + # entrypoint skips re-initializing an existing data directory, so the + # old credential is still the one actually enforced) — "password + # authentication failed for user mattermost" on every start + # afterward. Whether the data volume already has real data in it is + # what actually determines whether the old password is still live, + # not which reinstall mode was chosen. local DB_PASS="" MM_SECRET="" - if [ "$MODE" = "update" ]; then + local _db_has_data=false + [ -d db ] && [ -n "$(ls -A db 2>/dev/null)" ] && _db_has_data=true + if [ "$MODE" = "update" ] || [ "$_db_has_data" = true ]; then DB_PASS="$(grep '^POSTGRES_PASSWORD=' .env 2>/dev/null | cut -d= -f2-)" [ "$_HAD_EMBEDDED_COTURN" = true ] && MM_SECRET="$(grep '^COTURN_SECRET=' .env 2>/dev/null | cut -d= -f2-)" fi diff --git a/services/vaultwarden.sh b/services/vaultwarden.sh index 1cb635e..d7734c3 100644 --- a/services/vaultwarden.sh +++ b/services/vaultwarden.sh @@ -317,13 +317,23 @@ install_vaultwarden() { echo " SMTP (optional) — for password-reset and invite emails." echo " Press Enter to skip each field and configure SMTP later in .env." echo "" - local SMTP_HOST="" SMTP_FROM="" SMTP_USER="" SMTP_PASS="" SMTP_PORT="587" + # Every SMTP_* value (including PORT/SECURITY) stays genuinely empty + # unless SMTP_HOST is actually provided — confirmed live, this used to + # default SMTP_PORT to "587" and hardcode SMTP_SECURITY=starttls in the + # .env template unconditionally, so even a fully-skipped SMTP setup + # (SMTP_HOST left blank) still wrote real, non-empty values for those + # two. Vaultwarden reads that as "some SMTP config is present" and + # refuses to start ("Both SMTP_HOST and SMTP_FROM need to be set"), + # crash-looping even though the actual host/from fields were blank — + # the "skip SMTP" path was never actually clean. + local SMTP_HOST="" SMTP_FROM="" SMTP_USER="" SMTP_PASS="" SMTP_PORT="" SMTP_SECURITY="" prompt_text "SMTP host (e.g. smtp.gmail.com) [skip]:" "" SMTP_HOST if [ -n "$SMTP_HOST" ]; then prompt_text "SMTP port [587]:" "587" SMTP_PORT prompt_text "SMTP from address:" "" SMTP_FROM prompt_text "SMTP username:" "" SMTP_USER prompt_text "SMTP password:" "" SMTP_PASS + SMTP_SECURITY=starttls # Vaultwarden refuses to start at all if SMTP_HOST is set without # SMTP_FROM ("Both SMTP_HOST and SMTP_FROM need to be set") — # confirmed live, crash-loops on every start, not just a warning at @@ -333,7 +343,7 @@ install_vaultwarden() { # container — better than guessing a from-address on your behalf. if [ -z "$SMTP_FROM" ]; then log_warning "No SMTP from address entered — disabling SMTP entirely (Vaultwarden requires both or neither). Re-run this installer to set it up later." - SMTP_HOST=""; SMTP_PORT="587"; SMTP_USER=""; SMTP_PASS="" + SMTP_HOST=""; SMTP_PORT=""; SMTP_SECURITY=""; SMTP_USER=""; SMTP_PASS="" fi fi @@ -398,7 +408,7 @@ SIGNUPS_VERIFY=false # ── SMTP (optional — for password-reset and invite emails) ──────────────────── SMTP_HOST=$SMTP_HOST SMTP_PORT=$SMTP_PORT -SMTP_SECURITY=starttls +SMTP_SECURITY=$SMTP_SECURITY SMTP_FROM=$SMTP_FROM SMTP_USERNAME=$SMTP_USER SMTP_PASSWORD=$SMTP_PASS