Moving to Proxmox: permissions do not travel, and the role that sounds like "user" opens the console

A migration from vSphere to Proxmox carries not one line of the permissions table, and because the two tables look so alike in shape, almost nobody rebuilds theirs: they copy it from memory, going by the names of the roles. The disks arrive, each machine's configuration arrives, the networks arrive with effort. The permissions get redone by eye.

We have run Proxmox VE in production since the 3.x branches, we operate Ceph-backed clusters across several datacentres and we have migrated companies off VMware — we have also recommended staying on VMware when that made sense. This post is not about performance or licensing: it is about the half hour almost nobody puts in the cutover plan, and about a role whose name misleads.

The two tables look too much alike

The vSphere documentation puts it this way: "A permission is set on an object in the vCenter Server object hierarchy. Each permission associates the object with a group or user and the group's or user's access role". Proxmox's says an access rule "can be represented as a triple of (path, user, role), (path, group, role) or (path, token, role)". An object or a path, a user or a group, a role, and downward propagation on by default.

When two models share a shape, the brain assumes they share the contents. What ends up travelling is the feeling of having understood it.

The role that sounds like "user"

You arrive from vCenter looking for the most harmless role on the list to hand to someone who only needs to use their machine. You find PVEVMUser. The name is reassuring. The literal definition in the Proxmox documentation is: "view, backup, configure CD-ROM, VM console, VM power management".

Three of those five capabilities are console, CD-ROM and power. Together they describe someone sitting in front of the machine, with the disc tray open and the reset button within reach. The VM.Console privilege is documented in one line — "console access to VM" — and that line has a property worth reading slowly: the console does not go through the guest's network. There is no machine IP to reach, no firewall of its own to cross, no RDP or SSH published anywhere. You only need to reach the Proxmox management interface, which is a different door and usually lives on a different segment. You go in through the hypervisor and come out on the guest's screen.

The console gives you the screen and the keyboard: to log into the operating system you still need its credentials. What to look at is the combination. The fact that one role carries console, CD-ROM changes and power leaves an open question only your installation can answer: which storage can that user reach to pick an ISO, and are those machines' disks encrypted? If the answer to the first is "the same one the ISOs live on" and the answer to the second is "no", that role is not a user role. If neither applies, nothing dreadful happens — but then it is a decision somebody took, rather than a name that sounded right.

There is a fourth capability in the same role, and it is the quietest one: backup, documented as "backup/restore VMs". Back in August we wrote, after reading the code, that the "protected" flag on a backup is not a lock. Whoever can take and restore backups holds rather more sway over your restore points than the word "user" suggests.

The mapping table, gaps included

The inheritance rule that subtracts

Of the whole user management page, the sentence that costs the most is this one: "Permissions for individual users always replace group permissions". They replace. They do not add up.

Anyone coming from Active Directory brings the opposite reflex, built in over twenty years: group memberships accumulate. Here, if the sysadmins group holds PVEVMAdmin on /vms and you additionally give one of its members an individual entry on /vms/120 "so they can also do one specific thing", on that path that person now holds only what their individual entry says. You granted a permission and removed permissions in the same gesture. The same page adds two more sentences of the same kind: "Permissions on deeper levels replace those inherited from an upper level" and "NoAccess cancels all other roles on a given path".

None of this is a defect. It is a coherent model and it is written down. But it is a model that punishes the shortcut — the individual entry added in a hurry on a Friday — and the shortcut is exactly what happens the week after a cutover, when someone calls because they cannot do something and everyone is in a rush.

The privileges that reach inside the machine

During the migration you remove VMware Tools and install the QEMU guest agent: that is part of the script, and it is the right thing to do. What that agent opens on the other side is a family of privileges with no direct mental equivalent in the vCenter world. The descriptions in the Proxmox documentation are clear enough to be worth reading in full:

Reading and writing files inside the guest, from the hypervisor panel, without touching the guest's network. And the fact that this is split into five separate privileges is a virtue of the model. Having FileRead separate from FileWrite, and both separate from Unrestricted, lets you give an inventory system exactly what it needs and nothing more. The granularity is fine. What fails is that almost nobody gets to this page. People hand out PVEVMAdmin — "fully administer VMs" — and move on.

root@pam is not the vCenter administrator

The documentation says it without hedging: "The system's root user can always log in via the Linux PAM realm and is an unconfined administrator. This user cannot be deleted, but attributes can still be changed". That account is the node's Linux root. Its password lives on each machine. And the words that matter in that sentence are "cannot be deleted", because the identity policy you have just written so carefully has, by design, a door you cannot delete and that does not live in your directory. Delete it, no; what the other half of the sentence does say is «attributes can still be changed»: putting a second factor on it and taking it out of daily use is in your hands, and it is the first thing we do.

It is the same pattern we have described twice from other angles: the network configuration lives on each node, not on the cluster, and a Ceph key is not refreshed by rebooting the VM. In Proxmox some things live on the machine rather than on the whole, and they all share one symptom: nobody misses them until they are needed.

Four commands for the Monday after

All of this can be audited from the command line in less time than it takes to discuss it in a meeting. Four commands, and the output pasted into the migration handover document, with the date beside it:

The first returns the whole access table: path, who, and with which role. The second shows what each role actually contains, which is the only thing that ends the argument about names. The third, who exists and in which realm. The fourth, one person's tokens — and there the box to look at is privilege separation, --privsep, which is on by default for new tokens and whose effect the documentation describes like this: "Its effective permissions are calculated by intersecting user and token permissions". A token without separation carries everything its creating user has, and tokens are what ends up pasted into a backup system's configuration file.

And two questions no command answers. Who knows the root@pam password on each node, and where it is written down. And what happens the day that person leaves.

The limits of what we have just said

We are not saying Proxmox's permission model is worse than vCenter's. On the guest-agent side it is clearly finer-grained, and the exact composition of each predefined role may change between versions: the page that governs is the one for your version, read on the day you design the roles, not this post. Nor are we saying PVEVMUser is badly built; it is documented with a precision few vendors reach, and the one not reading it is us.

The conflict of interest, up front: designing roles and auditing access is work we bill for. If someone in your company already has the output of pveum acl list pasted into the handover document, dated and with a name beside every line, that part is solved and you do not need us for it.

Sources (verified on 4 October 2026): the definition of an ACL as a triple (path, user/group/token, role), the propagate flag on by default, the inheritance rules ("Permissions for individual users always replace group permissions", "Permissions on deeper levels replace those inherited from an upper level", "NoAccess cancels all other roles on a given path"), the available realms, the sentence on root@pam as an unconfined administrator that cannot be deleted, the list of predefined roles with their descriptions (PVEVMUser: "view, backup, configure CD-ROM, VM console, VM power management"; PVEVMAdmin: "fully administer VMs"; PVEAdmin: "can do most tasks, but has no rights to modify system settings or permissions"), the literal descriptions of VM.Console and of the VM.GuestAgent.* family, and API token privilege separation — User Management, Proxmox VE wiki and the pveum chapter of the administration guide. The syntax of pveum acl list, pveum role list, pveum user list, pveum user token list and the --privsep option (default 1) — pveum manual page. The definition of a permission in vCenter Server and the existence of system and sample roles — vSphere Security, VMware documentation.