[Bug] Client Portal , no console screen

[abyss1]

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

Ok so , when I go into the client portla and I click console the window opens but it never connects ot the console. It just sits there for a while shows conencting at hte top and then eventually goes to disconnected.

Steps to Reproduce

1. add any vm to the portal and a portal only user
2. press the consoel button in the bottom of the vm window
3. and nothign happens

Expected behavior

I expect liek in proxmox / pegaprox when I go on the consoel of the vm it see it and I can interact witht he vm directlly.

Environment

• PegaProx Version: 0.9.12.3
• Installation Method: Docker compsoe
• OS: Debian 13 as docker hsot , container what ever you isntalled
• Browser: Chrome , Firefox same behaviour
• Behind Reverse Proxy? No
• UI? Client Portal

Logs

There are no real logs as far as I know , if so please direct where I can find them for the client portal

Screenshots

Checklist

• [ x] I have searched existing issues to make sure this is not a duplicate
• [ x] I am using the latest version of PegaProx

[mkellermann97]

Thanks for the detail. The portal console isn't its own thing — like the main PegaProx UI it opens the VNC over a WebSocket on the container's port 5001 (the main app port + 1), which Docker has to publish. Plenty of compose files only map 5100:5000 and miss the console ports, which gives exactly this "Connecting…" that hangs and then drops — the browser never reaches the VNC socket (an auth refusal would disconnect instantly, not sit there). Check your compose publishes all three: 5100:5000, 5101:5001 (VNC), 5102:5002 (SSH), and that https://<host>:5101/ opens directly (accept the self-signed cert). The deciding test: does the console work from the main PegaProx UI as an admin — if it also hangs it's the port mapping; if the main UI works but only the portal hangs, that's a portal-side bug and I'll dig straight in. opencollective.com/pegaprox if PegaProx is earning its keep. — Marcus

[abyss1]

@setf-pegaprox ~ % netstat -tulpn
(No info could be read for "-p": geteuid()=30001 but you should be root.)
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:5001 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:5002 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:1514 0.0.0.0:* LISTEN -
tcp6 0 0 :::22 :::* LISTEN -
tcp6 0 0 :::5001 :::* LISTEN -
tcp6 0 0 :::5000 :::* LISTEN -
tcp6 0 0 :::5002 :::* LISTEN -
udp 0 0 0.0.0.0:1514 0.0.0.0:* -
udp 0 0 127.0.0.1:323 0.0.0.0:* -
udp6 0 0 ::1:323 :::* -

I would say 5001 is mapped right :)

That said it actually works in pegaprox directlly .. so suspected the portal bug ?

In the actual audit log in pegaprox I see the request comming in.

[mkellermann97]

Thanks — that netstat settles it: 5001/5002 are listening and published, so it isn't the port mapping after all. I dug into the portal console path and found the real bug — a coarse permission check was rejecting Client-Portal users before the per-VM console gate even ran, so the WebSocket auth failed and the window just sat at "Connecting…". Fixed on Testing: the per-VM authorization is now the authoritative check, so portal users who have access to the VM get through.

It'll go out in the next release — I'll give you a shout here when it's tagged, and if it still hangs after that, reopen and I'll dig back in. Cheers for the detailed back-and-forth; opencollective.com/pegaprox if you ever feel like chipping in. — Marcus

[mkellermann97]

Shipped in v0.9.13 🎉 — the Client-Portal console was being rejected by a coarse permission pre-check before the per-VM gate even ran; that's removed now, so portal users with access to the VM get through. Pull the new image — docker compose pull && docker compose up -d (the v0.9.13 image is published on ghcr) — then hard-refresh.

Closing as fixed — reopen if the portal console still hangs at "Connecting…" after the update. Appreciate the netstat and the back-and-forth that pinned it down. opencollective.com/pegaprox if it's been useful. — MK