Import from vmWare by non-admin user fails with '403' Permission error

[mii]

Hello,

when I use my own superuser account to perform a vmWare import via Wizard, this works fine.

Another user, having access to a resource pool, network, storage as required to create VMs, gets an error

403

permission denied after clicking "Import" in the import window.

I am guessing this has to do with the fact that the VMs are not put in a resource pool - and I don't see a way to select one in the wizard.

Any ideas?

 

[Römer]

Hi everyone,

I second that. The import UI (not just from ESX, but also via the new OVA upload) is lacking the possibility to select a resource pool. Hence the import cannot be used on system where granular access management based on pools is used (failing with a 403, similar as with VM cloning where a pool without permissions is selected).

Please advice on how work arounds or how this could be given attention for a fix.

Regards

 

[fiona]

For reference: https://bugzilla.proxmox.com/show_bug.cgi?id=6113

 

[AlterSchwede]

Hi,

according to my understanding, it is not good enough to add the Pool to the import wizard to solve the permission problem during ESXi-Import. Even if I grant full access to the Pools, I still cannot import a VM from my ESXi (got 403 error). But if I grant access full /vms access, it worked.
For me it looks like more than a pool problem.

Regards
Andreas

 

[fiona]

Hi,

according to my understanding, it is not good enough to add the Pool to the import wizard to solve the permission problem during ESXi-Import. Even if I grant full access to the Pools, I still cannot import a VM from my ESXi (got 403 error). But if I grant access full /vms access, it worked.
For me it looks like more than a pool problem.

currently, you cannot specify a pool during ESXi import via the UI, so the permission on the pools don't matter right now. The API endpoint for VM creation checks permissions on the pool if a pool is specified (which currently never is for ESXi import via UI), otherwise it checks permissions on the VM ID. That should explain the behavior you are observing.