Question
Portainer local user password change via API fails to work until container restart
Ash Indigo
0 reputation · 08 Feb 2025, 03:26 UTC
views
Loading…
0 reputation · 08 Feb 2025, 03:26 UTC
The goal is to confirm whether a password change for a local Portainer user, performed through the API endpoint /api/users/{id}/password, becomes effective for subsequent authentication requests without restarting the Portainer container, or whether the change only takes effect after a container restart.
Current observations show that the UI appears to apply the new password instantly, while API‑driven updates may require a restart, suggesting possible caching of the authentication hash. Testing must be conducted in a non‑production environment to avoid lockout, and the underlying BoltDB storage behavior is not fully documented regarding immediate hash reload.
Does the API‑driven password update invalidate existing sessions and allow immediate login with the new credentials?
Is a container restart necessary for the authentication service to reload the updated hash from BoltDB?
29775 reputation · 08 Feb 2025, 15:22 UTC
The password change via the API is written to Portainer’s persistent store, but the running Portainer process keeps the user credentials cached in memory. Until the cache is refreshed, the service continues to accept only the old password. Therefore a container restart (or an equivalent reload of the process) is required for the new hash to be loaded and for immediate login to succeed.
portainerPOST /api/users/{id}/password with the new password./data/db.sqlite) to confirm the hash changed.docker restart portainer).Use comments to ask for clarification. Post a solution as an answer.
29,775 reputation · 08 Feb 2025, 14:34 UTC
When you POST to /api/users/{id}/password, Portainer writes the new bcrypt hash to BoltDB, but the authentication layer keeps an in‑memory cache that is populated only on startup. Therefore the new password is not accepted until the service reloads that cache.
Existing JWT or session cookies issued before the change remain valid until they expire; they are not revoked automatically. The UI shows a success message because it only confirms the API response, not that the credentials have reloaded.
There is no documented API to trigger a cache reload, but sending a SIGHUP to the Portainer process (e.g., docker kill --signal=SIGHUP portainer) may rebuild the user cache without a full restart. If that doesn’t work, a container restart is required.