I just cant give up.....
Update — narrowed this down, and I think it's a token-indexing issue, not auth tokens being "deleted."
Background: this XO (from-source install) was built fresh and then had a config restored into it from an exported XO config backup. After the config import. I logged out as admin@admin.net and logged into my user account and then deleted the admin@admin.net account.
Here is what I've been able to prove:
Symptom: Every browser session token fails immediately after login. Seconds after logging in, xo-server logs:
xo:redis WARN The id xo:token:<id> had no attached entries.
…and then the v6 dashboard's REST/event calls all return 401:
[GET] /dashboard (401)
[GET] /vms (401)
[GET] /hosts (401)
[GET] /srs (401)
[GET] /backup-logs (401)
[GET] /pools/<uuid>/stats (401)
[POST] /events/<uuid>/subscriptions (401)
What I tested / ruled out:
Not a stale browser cookie. Fully closed the browser, logged in fresh. The brand-new token (visible in Settings → Tokens, created at login time) reproduces had no attached entries within ~40 seconds.
Not the reverse proxy. Reproduced on a direct connection to the XO server, no proxy in the path. (v6 does appear to load somewhat better direct vs. proxied, but the token warnings + 401s happen either way.)
Not stale Redis index data. I stopped xo-server, deleted xo:token::indexes (it's a Redis SET), and restarted — three separate times. XO rebuilds the key, but every newly-issued session token re-triggers the warning.
Only session tokens are affected. API tokens created via Settings → Tokens (with a description) work perfectly — they authenticate fine against the REST API via the authenticationToken cookie and never log this warning. The breakage is specific to browser-login session tokens.
My read: on this restored-from-config instance, xo-server issues a session token at login but cannot resolve that same token on the next request — it looks like the token body is written but its index entry is not (or the xo:token collection's index schema is in a state XO can't self-heal after a config import). API tokens are unaffected, which is why integrations keep working while the v6 dashboard 401s.
Likely trigger: restoring an exported XO config onto a fresh install. The imported state and the xo:token collection appear to end up inconsistent.
Questions for the team:
Is there a supported way to fully rebuild the xo:token collection index on a restored instance, beyond deleting xo:token::indexes?
Is this a known issue with config-backup restore leaving the token store inconsistent?
Happy to provide full logs or run diagnostics.
❯ journalctl -u xo-server -f | grep -iE 'had no attached|WNSCG|401'
May 22 00:50:12 xo-ce xo-server[42654]: 2026-05-22T00:50:12.370Z xo:rest-api:error-handler INFO [GET] /users/0344d88b-0fe8-4462-811b-5c04a92981aa (401)
May 22 00:50:12 xo-ce xo-server[42654]: 2026-05-22T00:50:12.507Z xo:rest-api:error-handler INFO [GET] /dashboard (401)
May 22 00:50:17 xo-ce xo-server[42654]: 2026-05-22T00:50:17.166Z xo:redis WARN The id xo:token:WNSCGIpaCV0zihqsT3L3lXMkwA6XWcTgoSmzfHXT5xM had no attached entries.
May 22 00:50:27 xo-ce xo-server[42654]: 2026-05-22T00:50:17.166Z xo:redis WARN The id xo:token:WNSCGIpaCV0zihqsT3L3lXMkwA6XWcTgoSmzfHXT5xM had no attached entries.
May 22 00:50:27 xo-ce xo-server[42654]: 2026-05-22T00:50:27.399Z xo:rest-api:error-handler INFO [GET] /srs (401)
May 22 00:50:30 xo-ce xo-server[42654]: 2026-05-22T00:50:30.201Z xo:redis WARN The id xo:token:Gy-WhZLuY-C5zmPLqx677VA9uP_v6G8_ZY8IsyPoBfo had no attached entries.
May 22 00:50:30 xo-ce xo-server[42654]: 2026-05-22T00:50:30.201Z xo:rest-api:error-handler INFO [GET] /backup-logs (401)
May 22 00:50:32 xo-ce xo-server[42654]: 2026-05-22T00:50:32.176Z xo:rest-api:error-handler INFO [POST] /events/5f61024f-480a-4673-aa87-1a13512804c4/subscriptions (401)
May 22 00:50:34 xo-ce xo-server[42654]: 2026-05-22T00:50:34.807Z xo:rest-api:error-handler INFO [GET] /backup-logs (401)
May 22 00:50:39 xo-ce xo-server[42654]: 2026-05-22T00:50:39.429Z xo:rest-api:error-handler INFO [POST] /events/b305b71b-1fb7-4dbd-ae1b-dd55ecf658c9/subscriptions (401)
May 22 00:50:39 xo-ce xo-server[42654]: 2026-05-22T00:50:39.530Z xo:redis WARN The id xo:token:WNSCGIpaCV0zihqsT3L3lXMkwA6XWcTgoSmzfHXT5xM had no attached entries.
May 22 00:50:44 xo-ce xo-server[42654]: 2026-05-22T00:50:44.445Z xo:rest-api:error-handler INFO [GET] /hosts (401)
May 22 00:50:44 xo-ce xo-server[42654]: 2026-05-22T00:50:44.447Z xo:rest-api:error-handler INFO [GET] /vms (401)
May 22 00:50:49 xo-ce xo-server[42654]: 2026-05-22T00:50:49.522Z xo:rest-api:error-handler INFO [POST] /events/3e83a79d-9386-4c36-801a-292734a05051/subscriptions (401)
May 22 00:50:50 xo-ce xo-server[42654]: 2026-05-22T00:50:50.730Z xo:rest-api:error-handler INFO [GET] /hosts/00fcd37d-e4c4-476e-a0ef-1ded027bebf8/alarms (401)
May 22 00:50:52 xo-ce xo-server[42654]: 2026-05-22T00:50:52.242Z xo:rest-api:error-handler INFO [POST] /events/3e83a79d-9386-4c36-801a-292734a05051/subscriptions (401)
May 22 00:52:40 xo-ce xo-server[42654]: 2026-05-22T00:52:40.784Z xo:redis WARN The id xo:token:Gy-WhZLuY-C5zmPLqx677VA9uP_v6G8_ZY8IsyPoBfo had no attached entries.
May 22 00:52:43 xo-ce xo-server[42654]: 2026-05-22T00:52:43.994Z xo:rest-api:error-handler INFO [GET] /pools/939ed551-fbd6-9868-52d8-d3997b7bf7da/stats (401)
May 22 00:52:45 xo-ce xo-server[42654]: 2026-05-22T00:52:45.872Z xo:redis WARN The id xo:token:Gy-WhZLuY-C5zmPLqx677VA9uP_v6G8_ZY8IsyPoBfo had no attached entries.
May 22 00:52:47 xo-ce xo-server[42654]: 2026-05-22T00:52:47.710Z xo:rest-api:error-handler INFO [GET] /pools/939ed551-fbd6-9868-52d8-d3997b7bf7da/stats (401)
