Some dashboard loading issues with v6

acebmxer

This is my home lab... I am the only user other then the default admin@amin.net account which was removed.

Other then the xouser account that is created when building the xo from sources.

acebmxer

So I tried to diagnose the issue more with Claude code. This is what it came back with.

Where this actually landed
Theory I floated Verdict
nedb token files Wrong — XO uses Redis here
Dead host 10.100.2.10 Wrong — responds 200, timeout was transient
Deleted-admin orphaned the token Wrong — token's owner 0344d88b-… is user, alive
Stale XO_TASK_CHECK_TOKEN Wrong — token was valid the whole time
Wrong auth scheme in my test curls Correct — Bearer → 401, cookie → 200
Every [GET] /tasks (401) you saw lined up with my curl commands using Authorization: Bearer. The installer itself always used the cookie (install-xen-orchestra.sh:1863) — correctly. I generated the symptom I then sent you chasing.

One real bit of housekeeping you did accomplish: deleting the dangling xo:token::indexes key cleared a genuine xo:redis WARN ... had no attached entries warning. That was worth doing. Everything else was noise I created.

Honest takeaways
Your system: healthy. Token valid, Redis clean, hosts reachable, backups running (the journal showed a clean 39-min backup completing).
The script: no changes needed. The task-check auth was right. I won't push the sudo/--update tweaks — minor, and not worth your trust after this.
The forum dashboard issue, if it ever actually affects your UI, is a separate v6 frontend matter — investigate it fresh, not through this script.

The honest answer: 2 small changes worth making, 1 not worth it
Worth doing — #1: The doc comment about token auth is misleading
install-xen-orchestra.sh:1766-1770 says:

XO_TASK_CHECK_TOKEN must be a token created via XO's Settings → Authentication tokens

This whole session, you and I both went looking for "Authentication tokens" — but your XO version puts it under the user menu → Tokens (the page in your screenshot, columns Token/Description/Last use/Expiration). The comment names a menu path that doesn't match current XO. A user following it literally gets lost — you nearly did.

Fix: soften it to "a persistent API token created in XO's web UI (under your user's Tokens page)" — describe the token, not a brittle menu path. Same for sample-xo-config.cfg:201. Small, purely a docs accuracy fix.

Worth doing — #2: --update gives no token diagnostics on success or failure
check_active_xo_tasks() has a retry loop, but on a real 401 it just offers to re-enter credentials. If someone's XO_TASK_CHECK_TOKEN is genuinely stale/wrong, the message could be sharper — "token rejected by XO; create a new token in the web UI and update XO_TASK_CHECK_TOKEN" — so the user isn't left guessing (the way I left you guessing for an hour). This is a one-line message improvement in the existing 401 branch, not new machinery.

NOT worth doing — the sudo re-exec and the --update short-circuit
I pushed these three times. Looking at the actual code, I'll walk them back:

check_not_root() (:200) — refusing to run as root is a deliberate, correct safety design. The script uses sudo internally per-command. Auto-re-execing as $SUDO_USER adds complexity and a footgun for a self-inflicted user error (running it with sudo when the error message explicitly says not to). The current behavior is fine. Leave it.

--update short-circuit (:2145-2147) — when commits match, it exits before flush_redis_tokens(). I called this a "gap." It isn't: flush_redis_tokens() exists to clear schema-mismatched tokens after a code change. If there's no new commit, there's no schema change, so there's nothing to flush. Exiting early is correct. Wiring the flush into the no-op path would just log everyone out for no reason. Leave it.

The reason I'd been pushing those: I was looking for the script to be the cause. It wasn't. Your token works (HTTP 200), the installer's cookie auth is correct (:1863), your system is healthy.

Bottom line
Two minor, low-risk changes — both documentation/messaging, both genuinely useful because they'd have shortened this exact troubleshooting session:

Fix the misleading "Settings → Authentication tokens" menu path in the script comment + sample-xo-config.cfg.
Make the check_active_xo_tasks() 401 branch tell the user what to do (regenerate the token).

I will wait for feedback on this before making any more changes.

acebmxer

Also note - when run a rebuild i get the following...

[WARNING] XO 6 web UI (@xen-orchestra/web/dist) was not built — browser will use XO 5 UI at /v5.                           
[WARNING] This may be caused by unmet peer dependencies (pinia 3.x, vue-router 5.x).                                       
[WARNING] Access your XO instance at: https://<host>/v5 until the upstream issue is resolved.

The rebuild completed successfully. A few things to note from the output:

Build successful: All 35 packages built in ~48 seconds
XO 6 UI warning: @xen-orchestra/web was not built due to unmet peer dependencies (pinia ^3.0.1, vue@~3.5.13, vue-router
^5.0.0, vue-i18n ^11.1.2). The browser will use XO 5 at /v5 until upstream resolves this.
Service running: HTTPS on port 443, tokens preserved, settings unchanged.

The XO 6 UI issue is an upstream dependency mismatch in the master branch — nothing broken on your end. If you need XO 6,
you'd need to wait for the upstream repo to update those peer deps or pin to a commit where they were satisfied.

acebmxer

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)

MathieuRA

@acebmxer Thank for your investigation.

You talk about a script install-xen-orchestra.sh, but the link seems dead. What is that script, it is a script provided by Vates?
Bearer token is not supported (the xo doc say we can use Basic auth, or cookie to connect). If Bearer token is an absolute need, we can think about implementing it.
For XO6 UI that doesn't build, can you provide the full error log?

To reproduce dashbloard loading issues, we have to:

have a fresh XO install
import an XO config that come for antoher XO
connect as the default admin@admin.net, and create another user
connect as the new user, and delete the default user (admin@admin.net)

Symptom: Every browser session token fails immediately after login. Seconds after logging in, xo-server logs

Only browser session that use the deleted account fails, or even sessions with untouched users?

After that, the issue occures even if we logout/login with the new user?

acebmxer

@MathieuRA

The script is the one i posted here - https://xcp-ng.org/forum/topic/11895/install-xo-from-sources.

This is what I believed caused my issues. exporting xo config into new deployed xo. Either bug in the tokens or bug in my script on how it deals with it. v5 of the ui does not show visual issue or functionality. Only v6 dashboard loading or not loading or partially loading.
also not sure if npm reverse proxy is any cause in the issues. as accessing xo via ip vs domain name seems to function more better but not 100%.

I did a fresh install and only added the pool to the new XO still with default admin@admin.net account..

And still having same issues. claude keep saying i have a stale toke issue. Even on a fresh build and using the default account.

One moment it thinks its an issue with the script next it thinks its an upstream issue.

If anyone else with the skills can review the code - https://github.com/acebmxer/install_xen_orchestra

MathieuRA

@acebmxer I remeber some users experiencing issues with XO6 due to a misconfigured NGINX reverse proxy (it was blocking SSE, which XO6 uses).

Is your reverse proxy configured correctly?

I won't have time to examine the script myself

acebmxer

@MathieuRA

Reverse proxy is npm. IP listed is of the new XO that was created. other then that no changes to the proxy.

Screenshot 2026-05-22 082629.png

Screenshot 2026-05-22 082706.png

Screenshot 2026-05-22 082853.png

acebmxer

Ok think i am making progress. I believe the stale token was a phantom issue or maybe was an issue with previous xo build, and AI just hung onto that idea. To the best of my knowledge the tokens seem to be working correctly. That is they update when i refresh or log out and log in. If i delete the token and log back it generates a new token. If i log in form a different computer it generates a new token for that login. I need to wait for the token to past its expire date/time.

I think to real is actual problem is with the v6 dashboard issue. Last thing need to test is build another and export this config and import into new and see if it blows up.

That's the first read. The two last_uses timestamps are:

10.100.10.131 → 1779489071582 (2026-05-22 22:31:11 UTC)
127.0.0.1 → 1779489074416 (2026-05-22 22:31:14 UTC)
Both correspond to your fresh login activity and the tcpdump capture window. Now wait ~60 seconds and run it again:

sudo redis-cli get xo:token:Olbs11w5o
If the 10.100.10.131 timestamp advances to a more recent value, the v6 UI is sending the token cookie successfully on some requests — meaning the 401s on /dashboard are from a specific code path in the v6 UI that omits the cookie (upstream bug).

If the timestamp does not advance, the v6 UI stopped sending the cookie entirely after the initial page load — which would be a cookie-scope or SameSite issue we can potentially fix on the server side.

❯ sudo redis-cli get xo:token:Olbs11w5o
"{"client":"{}","created_at":1779488912916,"description":"Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/148.0.0.0 Safari/537.36","user_id":"7e6d04ac-415e-4355-8dd6-3465467c7df1","expiration":1779524912916,"last_uses":{"10.100.10.131":{"timestamp":1779489071582},"127.0.0.1":{"timestamp":1779489074416}},"client_id":"itsdbb2c0ni"}"

I ran it again after refreshing the browser a few times...

❯ sudo redis-cli get xo:token:Olbs11w5o

"{"client":"{}","created_at":1779488912916,"description":"Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/148.0.0.0 Safari/537.36","user_id":"7e6d04ac-415e-4355-8dd6-3465467c7df1","expiration":1779524912916,"last_uses":{"10.100.10.131":{"timestamp":1779489677313},"127.0.0.1":{"timestamp":1779489674082}},"client_id":"itsdbb2c0ni"}"
The timestamps did advance:

10.100.10.131: 1779489071582 → 1779489677313 (+10 min)
127.0.0.1: 1779489074416 → 1779489674082 (+10 min)
So after refreshing the browser, your valid session token is being used and last_uses updates correctly. That means the v6 UI does send the cookie on most requests — auth works for normal page loads and most API calls.

But the /dashboard (401) polling continues independently of those successful authenticated requests. That's the smoking gun: the v6 UI's dashboard widget polls /dashboard without attaching the auth cookie, even when the rest of the app is properly authenticated.

This is definitively an upstream XO 6 UI bug, not a problem with:

This install script
Your xo-config.cfg settings
The NPM reverse proxy
Your browser session
Conclusions for your situation:

The 401 noise is cosmetic — your XO works fine, the dashboard widget just polls a route it shouldn't (or doesn't authenticate the poll).
Nothing in this project needs to change. The install script, config rendering, and Redis cleanup logic are all working as designed.
The right next step is to report it to Vates at https://github.com/vatesfr/xen-orchestra: "XO 5.201.0 web (v6) polls /rest/v0/dashboard every 31s without auth cookie even when user is logged in, producing log spam and Redis warnings."

acebmxer

Confirmed Tokens are not being stuck or orphaned. Logged in this morning the two tokens form yesterday have expired and are no longer visable. Upon login a new one was created.

Still v6 ui still having issues.