[Bug] Ressource Pool Userrights not working in the Clientportal

[mbo-nw]

Describe the bug

ClientPortal:
If you assign a user to a RessourcePool, the User has no access to any VM in the pool

Steps to Reproduce

1. assign vm's to a ressource pool
2. add user to pool (portal only user)
3. open /portal

Expected behavior

A user with pool rights should see all VM's assigned to the pool, otherwise you'll have to add each user manually to each VM in the VM-Rights tab, which ends up in an endless klicking story... eg. 5 users 40 VM's on 3 clusters

*** additional feature would be, if there are identical ressourcepools on different clusters, it would be nice to apply the ressource pool rights with the identical users to all cluster containing the identical ressource pools.

Environment

• PegaProx Version: 0.9.13
• Installation Method: git clone
• OS: Ubuntu 24.04 LTS
• Browser: any
• Behind Reverse Proxy? NO
• UI? standard /portal UI

Logs

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]

Hey @mbo-nw — thanks, and yeah, this is a real one. Confirmed in the code: pool membership is honoured on the per-VM permission check, but the cluster-access gate and the VM-list filtering only look at per-VM ACLs (plus tenant cluster assignments), not pool membership — so a portal user who only has rights through a resource pool gets filtered out at the gate and ends up seeing nothing. That's exactly why the per-VM workaround you described "works", and why it's such a clicking marathon.

The clean fix is to make the access gate + list filter pool-aware, the same way the per-VM check already is — but since this touches the access-control paths I'd rather it get a careful pass than a quick patch, so I'm handing it to @MrMasterbay. Your cross-cluster "same pool name → apply the same rights everywhere" idea is noted as a follow-up once the base case is solid.

If PegaProx is saving you some clicking, opencollective.com/pegaprox helps keep us at it 🙏

— MK

[mbo-nw]

If PegaProx is saving you some clicking, opencollective.com/pegaprox helps keep us at it 🙏

we are already platimum sponsor.

[mkellermann97]

Ha — noted, and genuinely, thank you for the Platinum support 🙏 That donation line is an auto-reflex I paste on bug replies; should've caught it here, sorry about that.

On the actual issue: the pool-rights gap is confirmed and sitting with @MrMasterbay now. Your setup (5 users / 40 VMs / 3 clusters) is exactly the scale this is supposed to handle, so it's not going to gather dust — I'll drop a note right here once the fix lands on Testing.

— Marcus

[mkellermann97]

Update — this is fixed on Testing. Pool membership is now honoured everywhere it was being ignored: the portal lists a pool's VMs to anyone with a grant on it (no more per-VM ACL marathon), and the cluster/console access gates got the same treatment. Verified end-to-end here — a pool-only portal user now sees exactly the VMs in their pool, and nothing outside it; pull the grant and the list goes empty again.

It'll ride the next release. Curious whether it holds up at your scale (5 users / 40 VMs / 3 clusters) once you're on it — give it a poke and let me know. And thanks again for the Platinum support 🙏

— Marcus

[mkellermann97]

Quick heads-up @mbo-nw — the pool-rights fix is live now in v0.9.13.1 (released last night), not just on Testing. Update at your convenience and a pool-only portal user should see exactly their pool's VMs — no more per-VM ACL marathon. I'd genuinely like to know it holds up across your 5 users / 40 VMs / 3 clusters once you're on it, so ping me here either way. Thanks again for the Platinum support 🙏 — Marcus

[mbo-nw]

Hello,
im sorry, but it's still niot working after the update. I have deleted all pool-rights and reassigned only on user for testing, but I still cant see any VM out of the pool, only VM's with explicite user-rights assigned.

kind regards
Michael

PS: we are currently running 4 clusters, 18 nodes, 320 Vm's, 12 ressource pools and about 25 users

[mkellermann97]

Sorry it's still not surfacing them, Michael — and thanks for the clean repro. The fix works on my test rig (a pool-only user sees exactly their pool's VMs and nothing else), so your setup is hitting a path mine isn't, and I'd rather pin that down than guess. Two things that'd let me reproduce it: (1) is the pool right assigned directly to the user or via a group the user is in — and which permission did you tick (pool.view? pool.admin)? (2) are these Proxmox resource pools (created in PVE, with the VMs as pool members) or PegaProx-side groupings? And if you can grab the server log around the moment that test user opens the portal — anything tagged [POOL] / [POOL-CACHE] — that usually points straight at it. We'll get you off the per-VM-ACL grind; thanks again for the Platinum backing and the patience. — Marcus

[mbo-nw]

Hello,

thnx for the feedback, I'll provide all your requested information tomorrow during the day.

ttyl
Michael

[mkellermann97]

Hi Michael — I dug into this properly instead of waiting, and I think I've found it. For a direct user-grant the pool→VM lookup is sound, so the failure is on the membership side: PegaProx asks the cluster for each pool's members, and if the cluster's API token lacks the Pool.Audit privilege it gets back nothing — and we then silently cached that empty result for 5 minutes, so a pool user saw zero VMs. Two parts to the fix: I've hardened that on Testing (an empty/failed lookup now retries quickly and logs a clear warning instead of sticking), and on your side the actual unlock is granting Pool.Audit to the API token PegaProx uses for each cluster (Datacenter → Permissions → add the token with a role that includes Pool.Audit, e.g. PVEPoolUser/PVEAdmin). After updating to the next build, could you check the PegaProx log for a line starting [POOL-CACHE] … lacks Pool.Audit — if it's there, the token grant is the fix; if not, tell me whether you assign the pool to a user or a group and I'll chase the group-matching path next. Thanks for your patience on this, and for the Platinum support.

— Marcus