Some dashboard loading issues with v6

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.

MathieuRA

@acebmxer Hi

i am able to reproduce the dashboard issue locally now, so we can also investigate on our end.

Can you confirm, no dashboard issue on the commit : ee53cd072304a38e8bf816dceef9bc7277b776dc?

acebmxer

@MathieuRA said:

@acebmxer Hi

i am able to reproduce the dashboard issue locally now, so we can also investigate on our end.

Can you confirm, no dashboard issue on the commit : ee53cd072304a38e8bf816dceef9bc7277b776dc?

Current commit running - Master 5811d
Current available - Master a9f85

Should i update to the latest or do you have a specific build/branch to try?