2.0 KiB
2.0 KiB
2026-08-07 — Bug: can't log in after first-run setup (password wrong) — root cause + fix
Symptom
After first login (admin/1234) → change password in the forced setup screen → logout → logging back in with the new password reports "wrong password".
Investigation (verified via reproduction)
- Backend
repro_loginin a temp data dir: first login (200, must_setup=true) → setup (200, must_setup=false, email set) → re-login with NEW password = 200 (works) → old password = 401. => Login logic is CORRECT. - Same flow over the LIVE localhost server via HTTP (created tester2, setup with new pw, re-login with new pw = 200). => Works end-to-end on a running server.
- Conclusion: not a login/setup code bug. The failure is DEPLOYMENT DATA NON-PERSISTENCE.
Root cause
On EasyPanel / any deploy that doesn't mount a volume, the container's DATA_DIR
(/app/backend/data) is ephemeral — wiped on every container recreate/restart. So after
setup, when the container is recreated:
- the changed admin password is lost (record resets to
1234/must_setup=true), - logging back in with the new password fails ("รหัสผ่านผิด").
Fix
- Dockerfile:
ENV DATA_DIR=/app/backend/data(explicit) +VOLUME ["/app/backend/data"]. - README: added a "Data persistence" section — must mount a persistent volume to
/app/backend/data(compose already does./data:/app/backend/data); EasyPanel must mount one. - Commit
334ef4e(+ earlier docker commit), pushed togit.moreminimore.com/kunthawat/sales-trainer.
How the user should apply
- EasyPanel: add a persistent volume mount →
/app/backend/data(or setDATA_DIRenv to a mounted path). After that, data survives redeploys. - If they already lost data (old password gone): delete/reset the container data so a fresh
admin/1234is bootstrapped, then redo setup and NEITHER redeploy without a volume.
Note
Local dev: backend/data/ is gitignored and lives on disk, so this only bites container deploys.