[Bug] Backup PBS

[surreal70]

Hey there! 👋 Thanks for taking the time to report this bug — we appreciate it!

Please keep in mind: PegaProx is developed and maintained entirely by volunteers in our free time. We do our best, but we can't work magic 🪄 — please be patient, we'll get to your issue as soon as we can.

Want to help keep PegaProx alive?

• ⭐ Star the project — it's free and helps a lot!
• 💖 Become a Sponsor — helps us dedicate more time to development
• 🤝 Contributing code or docs is always welcome too!

---

Describe the bug

Initiating a Patch of PBS. After hitting the Button to initiate Backup, the Resultsite is a blank white page.

Steps to Reproduce

1. Go to Patchmanagemnent
2. Select the Backupserver
3. Initiate the Patching
4. After a Browser reload the startpage is deisplayed.

Expected behavior

Return to context page, as it is done for PMX VE patching

Environment

• PegaProx Version: 0.9.10.2
• Installation Method: shellscript
• OS: Ubuntu 26.04
• Browser: Firefox 150.0.1 (snap canonical-02 - 1.0)
• Behind Reverse Proxy? No
• UI? Modern Layout

Logs

Screenshots

Checklist

• [yes ] I have searched existing issues to make sure this is not a duplicate
• [one behind :) ] I am using the latest version of PegaProx

classification

annoying, but work is possible.

[surreal70]

problem is also in the latest version. 0.9.10.3

[mkellermann97]

Hey @surreal70 — thanks for filing, and confirmed in v0.9.10.3 too per your follow-up.

Quick look at the PBS-update click handler in web/src/security.js around line 2867: it POSTs /api/pbs/<id>/update, shows a toast on success, then closes the modal via setShowPbsUpdateConfirm(null) — but unlike the PVE-side patch flow it doesn't navigate to a task-progress view. That alone shouldn't produce a blank-white-page, though — it should just leave you on the Patchmanagement page where you were. So something in the render-after-close path is throwing.

To narrow down the root cause, could you grab a couple of things from the browser session when you reproduce?

1. Browser console (F12 → Console tab) at the moment the page goes blank — any red errors? Especially React-style stack traces.
2. Network tab (F12 → Network) — does the POST /api/pbs/<id>/update actually return 2xx? Or 4xx/5xx with a body? The toast might be masking an error.

That'll tell me whether it's a frontend render-bug (React stack) vs a backend response-shape mismatch (the modal expecting a field that isn't there in the response) vs something else.

In the meantime: as you noted yourself, reloading lands you on the startpage, so the actual PBS update task started fine on the backend. The blank-page is purely a frontend post-click state issue, not the patch failing.

Donations at https://opencollective.com/pegaprox if narrowing-down-frontend-render-bugs earns its keep.

— Marcus

[surreal70]

[Theme] Initial load from localStorage: proxmoxDark 192.168.143.62:712:21
Theme applied: Proxmox Dark 192.168.143.62:706:21
[PWA] SW registered, scope: https://192.168.143.62/ 192.168.143.62:104:52
SSE: Waiting for user/session
Object { user: true, sessionId: false }
192.168.143.62:5988:46
[Theme] Login - Server theme: proxmoxDark Default: proxmoxDark Using: proxmoxDark 192.168.143.62:3776:240
Theme applied: Proxmox Dark 192.168.143.62:706:21
Connecting to SSE... 192.168.143.62:5989:396
SSE token obtained (expires in 600 s) 192.168.143.62:5989:175
SSE connected 192.168.143.62:5993:164
SSE authenticated, client: 8af8525c-6eb4-464b-b063-0c10fadc3a1d 192.168.143.62:6004:109
Cluster changed, fetching tasks for: 524d5577 192.168.143.62:5985:44
SSE tasks received for cluster 524d5577: 50 2 192.168.143.62:6005:94
SSE tasks received for cluster 524d5577: 50 192.168.143.62:6005:94
TypeError: line.includes is not a function
UpdateManagerSection https://192.168.143.62/:4250
UpdateManagerSection https://192.168.143.62/:4250
UpdateManagerSection https://192.168.143.62/:4250
React 10
poll https://192.168.143.62/:4224
react-dom.production.min.js:121:178
Uncaught (in promise) TypeError: line.includes is not a function
UpdateManagerSection https://192.168.143.62/:4250
UpdateManagerSection https://192.168.143.62/:4250
UpdateManagerSection https://192.168.143.62/:4250
React 10
poll https://192.168.143.62/:4224
192.168.143.62:4250:14035

[surreal70]

https://192.168.143.62/api/sse/updates?token=r7HeRcDnvF7zNcRfwxYdamkCXsBDxVpX
init by xhr
stated as Blockiert

[surreal70]

update, issue also occures with corporate theme

[mkellermann97]

@surreal70 — sorry for the two-week delay, this one slipped past the queue.

Re-reading your console drops from May: Blockiert on /api/sse/updates is the headline — Firefox 150 is refusing to open the EventSource, and the dashboard's live-update plumbing leans on it. The blank page is likely downstream of that SSE drop, not the POST itself — backend-side the POST /api/pbs/<id>/update returns in ~100ms (kicks an async task and that's it), so it's not a hung request.

Three things would narrow it down:

1. Dev-tools Network tab: response status + body of the POST /api/pbs/<id>/update row, and whether the page goes blank BEFORE or AFTER that response lands.
2. Console errors at the moment the page goes blank — anything red beyond the SSE-blocked line.
3. Reproducible on Chrome or a different browser on the same network, or Firefox-only?

If it's Firefox-only the next step is checking whether your install's Enhanced Tracking Protection is blocking the SSE URL on the private-IP origin (192.168.143.62), which is a known Firefox quirk in the 14x-15x range.

opencollective.com/pegaprox for the volunteer-hour pool — sorry again for the wait.

— Marcus