Backup access for users results in Permission check failed (/storage/null, Datastore.Audit(Datastore.AllocateSpace) (403)


New Member
Jun 5, 2023

Despite the User having Datastore.Audit and Datastore.AllocateSpace rights (on the VM and the Pool via the appropriate PVE roles) , we have the problem that we are not able to allow users to do a backup.

The backup tab is present but the user gets

Backup access for users results in Permission check failed (/storage/null, Datastore.Audit(Datastore.AllocateSpace) (403)

and the storage is not shown in the dropdown at the top

I am suspecting that we also have to give permissions to the appropriate storage called (I guess "/storage/null" is the null value in the UI ). Which is called "backup" and is a Proxmox Backup Server.

Is this possible?

Can it be configured, that only the backups of a user VM are accessible?

At the moment our users always have to write admin tickets to get both a backup schedule and the backup restored.

Many thanks in advance

The current permissions are managed mostly on pool level, we had:

VM.Console, VM.Clone, Pool.Audit, VM.Config.Options, VM.Config.CDROM, VM.Monitor, Pool.Allocate, VM.Config.Disk, VM.Snapshot, VM.PowerMgmt, VM.Allocate, VM.Snapshot.Rollback, VM.Config.Cloudinit, VM.Audit, Datastore.Allocate, Datastore.AllocateSpace, Datastore.AllocateTemplate, Datastore.Audit, Group.Allocate, Permissions.Modify, Realm.Allocate, Realm.AllocateUser, SDN.Allocate, SDN.Audit, Sys.Audit, Sys.Console, Sys.Incoming, Sys.Modify, Sys.PowerMgmt, Sys.Syslog, User.Modify,  VM.Config.CPU, VM.Config.HWType, VM.Config.Memory, VM.Config.Network, VM.Migrate

and I added

VM.Backup, Datastore.AllocateSpace , Datastore.Audit

but I still got the error above.
Hi, we ran into the same problem.
Just add under "Permissions" the path "/storage" for the user or group and it works...
  • Like
Reactions: The Kobold
could you please give a clear description of your ACL setup that triggers the error? (ideally the full user.cfg, you can censor sensitive information but please do so in a manner that preserves the contents, e.g., always replace a username X with the same string)





Do you need more info?
right before the last update everything worked without the "/storage" path...
creating a backup has always required write access to the backup target storage.. the error message could probably be better though!
Hi Fabian,
the only thing different from about a week ago ist the path entry.
And thanks for the attemt to improve the error message :)
which package versions were involved in the upgrade? (/var/log/apt/history.log should tell you)
The last update on June 28 included:

Start-Date: 2023-06-28  13:20:36
Commandline: apt-get --no-install-recommends -o Dpkg::Options::=--force-confnew install -- ceph ceph-common ceph-mds ceph-fuse gdisk
nvme-cli ceph-volume
Install: python3-paste:amd64 (3.5.0+dfsg1-1, automatic), python3-webtest:amd64 (2.0.35-1, automatic), ceph-volume:amd64 (17.2.6-pve1)
, python3-dateutil:amd64 (2.8.1-6, automatic), libfmt7:amd64 (7.1.3+ds1-5, automatic), ceph-mgr-modules-core:amd64 (17.2.6-pve1, auto
matic), python3-cherrypy3:amd64 (8.9.1-8, automatic), cryptsetup-bin:amd64 (2:2.3.7-1+deb11u1, automatic), python3-cffi-backend:amd64
(1.14.5-1, automatic), libthrift-0.13.0:amd64 (0.13.0-6, automatic), libqt5core5a:amd64 (5.15.2+dfsg-9, automatic), python3-lib2to3:
amd64 (3.9.2-1, automatic), ceph-base:amd64 (17.2.6-pve1, automatic), python3-ceph-common:amd64 (17.2.6-pve1, automatic), librgw2:amd
64 (17.2.6-pve1, automatic), python3-waitress:amd64 (1.4.4-1.1+deb11u1, automatic), python3-logutils:amd64 (0.3.3-7, automatic), libq
t5network5:amd64 (5.15.2+dfsg-9, automatic), libqt5dbus5:amd64 (5.15.2+dfsg-9, automatic), libdouble-conversion3:amd64 (3.1.5-6.1, au
tomatic), python3-werkzeug:amd64 (1.0.1+dfsg1-2, automatic), nvme-cli:amd64 (1.12-5), shared-mime-info:amd64 (2.0-1, automatic), pyth
on-pastedeploy-tpl:amd64 (2.1.1-1, automatic), librdkafka1:amd64 (1.6.0-1, automatic), ceph-mds:amd64 (17.2.6-pve1), ceph-mgr:amd64 (
17.2.6-pve1, automatic), ceph-mon:amd64 (17.2.6-pve1, automatic), ceph-osd:amd64 (17.2.6-pve1, automatic), libpcre2-16-0:amd64 (10.36
-2+deb11u1, automatic), python3-openssl:amd64 (20.0.1-1, automatic), python3-mako:amd64 (1.1.3+ds1-2, automatic), python3-soupsieve:a
md64 (2.2.1-1, automatic), uuid-runtime:amd64 (2.36.1-8+deb11u1, automatic), python3-natsort:amd64 (7.1.0-1, automatic), python3-bs4:
amd64 (4.9.3-1, automatic), python3-simplegeneric:amd64 (0.8.1-3, automatic), python3-markupsafe:amd64 (1.1.1-1+b3, automatic), pytho
n3-pecan:amd64 (1.3.3-3, automatic), python3-singledispatch:amd64 (, automatic), python3-pastedeploy:amd64 (2.1.1-1, automat
ic), python3-rgw:amd64 (17.2.6-pve1, automatic), python3-yaml:amd64 (5.3.1-5, automatic), ceph:amd64 (17.2.6-pve1), sudo:amd64 (1.9.5
p2-3+deb11u1, automatic), python3-distutils:amd64 (3.9.2-1, automatic), python3-bcrypt:amd64 (3.1.7-4, automatic), python3-webob:amd6
4 (1:1.8.6-1.1, automatic), python3-cryptography:amd64 (3.3.2-1, automatic), libsqlite3-mod-ceph:amd64 (17.2.6-pve1, automatic), libl
ttng-ust-ctl4:amd64 (2.12.1-1, automatic), python3-tempita:amd64 (0.5.2-6, automatic), liblttng-ust0:amd64 (2.12.1-1, automatic)
Upgrade: librados2:amd64 (14.2.21-1, 17.2.6-pve1), ceph-fuse:amd64 (14.2.21-1, 17.2.6-pve1), librbd1:amd64 (14.2.21-1, 17.2.6-pve1),
ceph-common:amd64 (14.2.21-1, 17.2.6-pve1), python3-cephfs:amd64 (14.2.21-1, 17.2.6-pve1), libcephfs2:amd64 (14.2.21-1, 17.2.6-pve1),
libradosstriper1:amd64 (14.2.21-1, 17.2.6-pve1), python3-rbd:amd64 (14.2.21-1, 17.2.6-pve1), python3-ceph-argparse:amd64 (14.2.21-1,
17.2.6-pve1), python3-rados:amd64 (14.2.21-1, 17.2.6-pve1)
End-Date: 2023-06-28  13:20:58

Up until then the user had access to the storages...
that seems very unlikely, since that set of packages doesn't involve anything that relates to the PVE code..

the checks for storage access have also been there for ages - maybe you modified the ACLs together with the ceph installation?
@riedel could you maybe also provide your (broken) user.cfg contents? thanks!
that seems very unlikely, since that set of packages doesn't involve anything that relates to the PVE code..

the checks for storage access have also been there for ages - maybe you modified the ACLs together with the ceph installation?
not knowingly, as only I am working on these kinds of settings.
@riedel could you maybe also provide your (broken) user.cfg contents? thanks!
the user.cfg before and after differed only in these lines:


(I checked agains the version from June 15)

thanks to your hint: I made it work by adding


As already discussed: the error seemed weird, and I could actually not find the storage permissions in the UI.

I am now, however, wondering if I did it correctly, or if I should rather add backup to all the pools as this also exposes the permissions correctly via the UI




PS:Sorry for the late reply. There was vacation and the problem only popped up now again.
Last edited:
I assume user@ldap is in your @staff group? if so, the difference between adding it to the pool ACL or on its own is just whether the other users in @staff get it as well.. (and that going via the pool means the privs of that role are also set on the VM paths, but that has no effect)


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!