clone vm but rights problem


Renowned Member
Nov 20, 2014
I do have a problem with the clone vm. My specific api user is PVEAdmin but he got always forbidden if he tries to clone a vm (template).
I really miss something which tells the which specific right is missing.
My own user has the administrator role and he can for sure clone the vm.
But the only difference is just something not important. Or do I missed someting ?

Administrator has additonal:

Thats nothing which is listed at the API explanation. Or ?
on which paths does the user has this permission
in order to clone a vm the user also has to have permission on the target path

existing vmid 100: /vms/100
new vmid: 200: /vms/200

to clone from 100 to 200 the user needs the permission on both paths (or on /vms with propagate on, or on a pool which contains that paths)
thats clear for me. The user has
1> 'path': '/vms/1001', 'roleid': 'PVEVMAdmin',
2> 'path': '/', 'roleid': 'PVEAuditor',
3> 'path': '/', 'roleid': 'PVEAdmin'

The task is to clone 1001
I guess the problem is that the first role overrules the third one cos of more detailed path.

My expectation is that it is an OR not an AND if roles are merged on the target VM.

An /vms/1001 PVEVMAdmin should add rights to the rights you have on the whole cluster not remove the more general ones
even more irritated. Just took all the rights the user has

so source is VM Clone allowed

[{'path': '/vms/1001', 'roleid': 'PVEVMAdmin', 'rights': ['VM.Backup', 'VM.Config.Disk', 'VM.Console', 'VM.Migrate', 'VM.Config.CPU', 'VM.Snapshot', 'VM.PowerMgmt', 'VM.Config.CDROM', 'VM.Config.Options', 'VM.Config.Memory', 'VM.Config.Network', 'VM.Clone', 'VM.Snapshot.Rollback', 'VM.Monitor', 'VM.Audit', 'VM.Config.HWType', 'VM.Allocate']},
{'path': '/', 'roleid': 'PVEAuditor', 'rights': ['Datastore.Audit', 'VM.Audit', 'Sys.Audit']},
{'path': '/', 'roleid': 'PVEAdmin', 'rights': ['VM.Backup', 'VM.Config.Disk', 'VM.Console', 'Sys.Console', 'VM.Migrate', 'Permissions.Modify', 'VM.Config.CPU', 'VM.Snapshot', 'Datastore.Audit', 'VM.PowerMgmt', 'VM.Config.CDROM', 'VM.Config.Memory', 'VM.Config.Options', 'Group.Allocate', 'Sys.Audit', 'VM.Config.Network', 'VM.Clone', 'VM.Monitor', 'Pool.Allocate', 'VM.Audit', 'VM.Snapshot.Rollback', 'Realm.AllocateUser', 'VM.Config.HWType', 'Datastore.Allocate', 'Datastore.AllocateTemplate', 'User.Modify', 'Datastore.AllocateSpace', 'VM.Allocate', 'Sys.Syslog']}]

API Docu says
You need 'VM.Clone' permissions on /vms/{vmid}, and 'VM.Allocate' permissions on /vms/{newid} (or on the VM pool /pool/{pool}). You also need 'Datastore.AllocateSpace' on any used storage.
Check: ["and",["perm","/vms/{vmid}",["VM.Clone"]], ["or",["perm","/vms/{newid}",["VM.Allocate"]],

should all are given by the above roles
do you have enabled 'propagate' ? if not, then the acl for '/' is really only for '/' and not for '/vms/YYYY'

can you post your '/etc/pve/user.cfg' ?
I shorten the file a lot.
user:pyprox@pve:1:0::::for RegtestLibraryFunctions::



I guess the 1 is propagate and thats the default for all
Last edited:
those lines look weird, are they like this in the file?(there seem to be ':' missing)
let me see ... At the beginning it showed always smileys in stead of @p: ...

and yes there was something lost.

user:pyprox@pve:1:0::::for RegtestLibraryFunctions::



Do you already have a Commercial Support Subscription? - If not, Buy now and read the documentation
Yes we do have community subscription and have reed the documentation too
And at the end the question is why not telling the missing right at the API response ?
OK issue cleared.
  • Permissions for individual users always replace group permissions.
replace is the nasty one.
If the user is member of Admin group
and has the role PVEAuditor

-> he is just PVEAuditor

The shorten user.cfg was too short :-(

But this is worse. At least on the same level group and user rights should be an extension not an contradiction.
Even on more specific level a high grade role should not be overwritten by a low grade rule. I now there is no weighting between roles but in fact these makes things worse especially with unclear fault messages. (forbidden)
this is intended and documented:

As mentioned earlier, object paths form a file system like tree, and permissions can be inherited down that tree (the propagate flag is set by default). We use the following inheritance rules:

  • Permissions for individual users always replace group permissions.

  • Permissions for groups apply when the user is member of that group.

  • Permissions replace the ones inherited from an upper level.
even if intended it must not be good... Seems to make the common right handling vice versa. But yeah... Its written somewhere in the deep. No the request could be at least to have more informative error messages


The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!