Also..
Thank you for taking a look at it and solving it so quickly, @florent
It is a quite nice interaction when reporting bugs that they are looked at and triaged. Not saying everything needs to be a priority 1. But I do appreciate being close to the process. And if I can help make things better by reporting bugs, in a hopefully constructive way. Then I'll continue to contribute my way.
@florent said in Setting "Protect from accidental deletion" breaks with backups and healtchecks:
the fix is merged into master
I can confirm that the problem has now been solved. And will mark the raised github-issue as closed as well.
@Greg_E
or just uncheck the "protection"-flag. But that get tedious very quickly. And I only had to do it on 6 VMs.
@greg_e & @florent
I have gone back through the commits, and I believe it is 0a042d2f54a74ecc11a377809272337cb5c880d9 that introduces the bugg.
https://github.com/vatesfr/xen-orchestra/commit/0a042d2f54a74ecc11a377809272337cb5c880d9
My last known good and working commit is the one just prior to it, a831ac7b213eb6fc7f05fbd466407d5cf379cfe9.
Tried with the latest commit (as the time of writing). 91c5d98489b5981917ca0aabc28ac37acd448396. But this didn't fix it, unfortunately.
Filed a issue/bugg-report on github for this
https://github.com/vatesfr/xen-orchestra/issues/9472
@pilow
A lot of updates can, and do, happen in a month or two 
I didn't have this before yesterday, which is when I updated. And I update from source regularly. So the regression has happened since the last few (<1w) days.
I'll step backwards and see which commit introduced the bug.
Manually unchecking makes the problem go away..
And I can also delete manually (after unchecking the HC-vms)
Having the flag "Protect from accidental deletion" has since yesterday left me with plenty of restored VMs. In the backup logs, it indicates that this happens during the healthcheck.
This has happened on 3 out of 6 VMs
Update: The other 3 VMs were opt-out from Healthchecks. So that is why this didn't affect them.
commit: dd5f0cdaa9993fae25469bd1cb1d01d4f2123f44
transfer
Start: 2026-02-04 12:16
End: 2026-02-04 12:16
Duration: a few seconds
Size: 2.01 GiB
Speed: 81.14 MiB/s
health check
transfer
Start: 2026-02-04 12:16
End: 2026-02-04 12:35
Duration: 19 minutes
vmstart
Start: 2026-02-04 12:35
End: 2026-02-04 12:35
Start: 2026-02-04 12:16
End: 2026-02-04 12:35
Error: forbidden operation: destroy is blocked: protected from accidental deletion
Start: 2026-02-04 12:15
End: 2026-02-04 12:35
Duration: 20 minutes
Error: forbidden operation: destroy is blocked: protected from accidental deletion
Clean VM directory
cleanVm: incorrect backup size in metadata
merge
Start: 2026-02-04 12:40
End: 2026-02-04 12:41
Duration: a minute
Start: 2026-02-04 12:40
End: 2026-02-04 12:41
Snapshot
Start: 2026-02-04 12:41
End: 2026-02-04 12:41
said in 
️ XO 6: dedicated thread for all your feedback!:
Windows guests Console - Reloads every 5-10s.
When trying to use the console for both my Windows 11 and Server 2025. The console reloads every 5-10s. This makes it borderline unusable. Since it resets the viewport/window scroll placement as well. Also the console seems to loose focus when this happens as well. Leading to have to click the console-section to get it in focus, to receive I am not seeing this behaviour in XO5 at all.
.
.
.
.
Unfortunately this is still present in commit 0a0ae5dc7ea6608612d105f6338ffe72d8bd9ed1 as well..
Update: I recorded the behaviour, for better clarification:
https://www.youtube.com/watch?v=PXpBFgSl31U
I've updated and added a node.js-installation to the role. Targeting the LTS-24 version.
I hope you find it to your liking.
Windows guests Console - Reloads every 5-10s.
When trying to use the console for both my Windows 11 and Server 2025. The console reloads every 5-10s. This makes it borderline unusable. Since it resets the viewport/window scroll placement as well. Also the console seems to loose focus when this happens as well. Leading to have to click the console-section to get it in focus, to receive I am not seeing this behaviour in XO5 at all.
I do not see the same behaviour on Linux (Ubuntu 24.04) guests. But they are cli-only. No X/Wayland
Commit: b89c26459cfd301bb92adf0a98a0b2dbab57e487
node: 24.12.0
Management agent 9.1.100-59 on both VMs
Windows 11 has GPU passthrough & bios
Windows Server 2025 - no GPU passthrough , uses uefi
@Mathieu said in ️ XO 6: dedicated thread for all your feedback!:
Has anyone tried to access XO 6 via a reverse proxy?
I'm using nginx proxy manager in a docker container to access my XO instance.
Everything is working fine with XO5 (both XOCE and XOA).
But when trying to access XO6 through the reverse proxy, it shows only a few info, with a circle loading on the top and nothing on the left bar:
If I access XOCE and XOA v6 by their IP address, it's working as expected.
Websocket support and cache is activated on the reverse proxy, nothing else fancy on that side.
Thanks.
I haven't tried ngnix. But I access my though haproxy:443 - > xo:8443. And that works just fine. But there needed to be a couple of fixes upstream in master to iron out the quirks with non-443 ports and such.
Replying back, that with commit 5fcb6db32e884e7d7d4cc2bb7430532201a45699 the graphics for 2FA look as they should
@olivierlambert said in 2FA doesn't load graphics properly after XO6 went default (XO from source):
Does it work OK without the proxy?
Testing on my secondary lab, and the results are the same. Secondary lab runs privileged service, 443 without proxy.
Since XO6 went default. The 2FA has been a bit wonky. See screenshot from chrome console.
Logins work as they should though. So there is no problem there.
My setup runs on port 8443, behind a haproxy.
Thanks for your feedback. I'll look into it over the christmas hollidays
@MathieuRA said in XO5 breaks after defaulting to XO6 (from source):
@probain branch
mra-fix-secure-port
Success!! Amazing. Thank you so much
@MathieuRA said in XO5 breaks after defaulting to XO6 (from source):
@probain I will prepare a branch for a potential fix, so you can still use the 8443 port
Absolutely fantastic. I will test it as soon as possible to help out however I can.
Cheers!
@MathieuRA said in XO5 breaks after defaulting to XO6 (from source):
@probain If you can, it will help a lot. Thanks
I remember why I chose to use 8443. It is because the xo-user running the service isn't running with root privileges. So doing it with an ordinary user was way more difficult to setup than just use 8443.
But...
Switching over so that service-user runs as root. 443 becomes possible. And things work again as expected. However, I really did like not running xo-server as root.
@MathieuRA said in XO5 breaks after defaulting to XO6 (from source):
Web server listening on https://[::]:8443
Well, I may have an idea about your issue.
The code is looking for the port443to know if he should use secure protocol ('wss:' / 'https:')
Is your second lab also in https on the 8443 port?
Hmm, no the second lab is more "standard" and uses 443.
I can try and set 443 on the primary lab as well to test.
@MathieuRA said in XO5 breaks after defaulting to XO6 (from source):
@probain That's what I was looking for.
It's strange you are saying you receive an error:
("Cannot get /")because logs show/is mounted and exposes XO6.
Dec 16 16:54:04 xo xo-server[50694]: 2025-12-16T15:54:04.452Z xo:main INFO Setting up / → /opt/xen-orchestra/@xen-orchestra/web/distEven when I did the same "fixes" that helped my second lab.
The only difference with your second lab is that you use HAProxy?
Both are listening on IPv6?
I reverted those changes from above with the [http.mounts] and [http.proxies] parts. Since that broke things even more. Sorry, I should've clarified that. I've pretty much reverted all of my troubleshooting experiments. In hopes to make it more clear if certain troubleshooting steps are needed.
My primary lab uses Haproxy. The second one doesn't (second lab doesn't run unprivilged either).
The logs I shared, were from the latest commit 32b3c0b5fcba17585566f0981ef62bef74c56451 (I believe).
