I granted permission but it does not apply: the path question in Proxmox permissions

A Proxmox permission is not a role on its own. It is who, which role, and at which path, all three together. The most common problem is a role granted at the wrong point.

AtlasPVE ·

This entry answers

  • proxmox permission not working
  • proxmox user permissions
  • what is proxmox acl path
  • proxmox assign role
  • proxmox user cannot see vm

The user was created, a role was granted, it was saved. Then the user logs in and sees nothing on screen. This is the most common permission confusion in Proxmox, and it almost always comes from the same place.

A permission has three parts

In Proxmox a permission does not mean "this user got this role". It has three parts: who, which role, and at which path. The path is the system's map in tree form: the root, a single virtual machine, a storage area, a node, a pool. You grant the role on a branch of the tree, and the role applies only there.

So behind the sentence "I granted permission but they cannot see it" there is usually this: the role is right, the user is right, the path is wrong.

The second trap: does it reach the branches below

Whether the permission covers the branches below is a separate choice made when granting it. If it does not, the permission applies at exactly that point and nowhere under it. A permission that does not flow down from where it was set is granted on paper and touches nothing in practice.

The third trap: what is inside the role

Role names are reassuring, their contents are not always what you expect. Seeing a virtual machine is one privilege, starting it is another, attaching to its console is another again. If the user can see the machine but cannot start it, the role is short, not the path. Separating those two is half the diagnosis.

The fourth trap: storage is forgotten

Permission to create a virtual machine is granted, permission on the storage is not. The user tries to build one and the error they get looks like it is about the machine, when the real question is where the disk gets written. If a job touches more than one branch, the permission is needed on more than one branch too.

The fifth trap: same name, different user

The domain at the end of a username is the authentication source. The same name in two different sources is two different users. If the permission goes to one and the login happens with the other, nothing works and nothing looks wrong on screen either.

How to diagnose it

Instead of reading the entries you created and reasoning from them, ask the system directly: what permissions does this user actually have. The answer tells you what the system applies, not what you granted, and the gap shows up exactly there. Permissions coming through a group add up as well; you do not take back a permission granted in one place by adding another entry.

What Atlas does

Atlas does not build its own role system. It asks Proxmox what the account signing in is allowed to do and shapes the screen from that answer, so the authority shown in the panel and the authority on the server do not drift apart. When you grant a permission the path arrives as a ready choice rather than a field typed from memory, and whether it reaches the branches below is a visible checkbox rather than a hidden default. Existing entries sit in one list, so the question "who was given what" is answered by reading.

Sources

Proxmox's own documentation. In English, and it has the final word on this subject.

Related entries

How does this look inside Atlas?

Go to the product page