Skip to content

Login / 2FA issues

Wrong password entered multiple times

The login endpoint is rate-limited: 10 requests per minute per IP. After too many failed attempts in a short time, the server blocks further attempts for a short while (HTTP 429) — that protects against brute-force, but can feel like a lockout to the affected user. Fix: wait briefly, then try again; for an actual lost password an admin resets it (Admin → Access → Users).

2FA code isn't accepted

  • Authenticator app (TOTP): the time on the phone and on the server must be in sync (TOTP is time-based) — for "invalid code" first check the system clock on both sides.
  • Security key (WebAuthn): needs an actively configured relying party ID on the instance — if WebAuthn isn't set up, the option doesn't even appear as a selectable factor.

2FA lockout

5 failed attempts at code entry trigger a 30-minute lockout (HTTP 429 with a Retry-After header). During the lockout, only waiting or an admin reset (see below) helps.

Completely locked out (no authenticator, no security key, no backup codes)

This is the case that has an explicit admin path:

Admin → Access → Users → affected user → "Reset 2FA"

Resets the user's 2FA method entirely to "none" (an audit entry is written). The user has to set it up again on the next login — and is then subject again to any 2FA mandatory rule that applies to them (the grace period applies again).

Prerequisite: there must still be at least one super admin who can log in themselves to perform the reset. If nobody has access anymore (e.g. the only admin account is itself locked out), the only remaining option is the server-side emergency admin bypass — see Admin access & split-container.

Lost WebAuthn backup codes

Backup codes are mandatory when setting up WebAuthn (no setup without them) and are shown once. Generating new codes only works with a fresh factor proof (WebAuthn or a remaining backup code) from within the last 5 minutes — a plain login cookie deliberately isn't enough for that. If all codes are used up and the key isn't available, only the admin reset above remains.

A 2FA mandatory rule blocks the login

If a 2FA mandatory rule (Admin → Access → 2FA) applies to a user, a role, a permission, or an entire tenant, and the grace period has expired without the required factor being set up, the login is blocked entirely until the matching factor is set up. That's not a bug — the rule is working as configured. Check the grace period and whether the user should be entered as an exception (e.g. service accounts without interactive login).

Details: 2FA.

"Account deactivated"

The user account was set to inactive in administration instead of being deleted (the usual path, because audit log references and dashboard ownership are preserved). Fix: Admin → Access → Users → activate the user.

Server clock wrong

"Token not yet valid" or "token expired" right after login points to an incorrectly set server clock — JWTs and TOTP codes are time-critical. Fix: set up NTP on the server (check/enable timedatectl), then try again.

Frontend shows "login failed" after a domain change

After a server URL change, the browser may have a cached old API base URL. Fix: clear the browser cache, hard reload — see UI issues after an update, same mechanism.

The interface reloads endlessly and the login screen never appears

If a session expired while a leftover cookie stayed in the browser, the interface could hang in a loop before v1.9.446: it sent you to the login, immediately considered you logged in again and reloaded the dashboard. Only the browser in which this state arose was affected.

Fixed in v1.9.446: logging out now removes every marker the interface uses to recognise "logged in", and a short block after logout applies even if a cookie cannot technically be deleted. On an older version, clearing the site data for that address helps.

The same root cause produced "CSRF token missing or mismatched" when saving after switching the separate admin container on or off: the browser held two identically named session cookies from the old and new scope. From v1.9.446 the server checks against both and clears the old set as well.

Login answers with "502" (v1.9.446 only)

On v1.9.446 the response to login, 2FA confirmation and silent session renewal could exceed the nginx header buffer ("upstream sent too big header") — nobody could get in, and running sessions ended after 30 minutes. Fixed in v1.9.447.

If you are stuck on v1.9.446 and cannot reach the interface: run docker compose pull && docker compose up -d on the server — or, as an immediate measure, set proxy_buffer_size 16k; in the nginx container and run nginx -s reload.

Next