Restoring a container backup that has an idmap fails via PVE GUI, but works fine via CLI

[kayson]

I have a CT with the following config (last lines added by me manually, to map IDs for Free-IPA and to squash root):

arch: amd64
cores: 1
features: nesting=1
hostname: idp00
memory: 2048
net0: name=eth0,bridge=vmbr0,firewall=1,hwaddr=bc:24:11:a5:3d:9c,ip=dhcp,tag=17,type=veth
onboot: 1
ostype: centos
rootfs: GlusterSSD:100/vm-100-disk-0.raw,size=8G
swap: 512
unprivileged: 1
lxc.idmap: u 70000 70000 10000
lxc.idmap: g 70000 70000 10000
lxc.idmap: u 0 100000 65536
lxc.idmap: g 0 100000 65536

If I try to restore a backup from my PBS from the web gui, it fails with

recovering backed-up configuration from 'PBSGlusterHDD:backup/ct/100/2026-06-04T08:00:03Z'
Formatting '/var/lib/vz/images/104/vm-104-disk-0.raw', fmt=raw size=8589934592 preallocation=off
Creating filesystem with 2097152 4k blocks and 524288 inodes
Filesystem UUID: e86e70ba-bd4d-4c44-a7a6-976f809b5f39
Superblock backups stored on blocks: 
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632
restoring 'PBSGlusterHDD:backup/ct/100/2026-06-04T08:00:03Z' now..
Error: error extracting archive - encountered unexpected error during extraction: error at entry "70003": failed to extract file: failed to set ownership: Invalid argument (os error 22)
TASK ERROR: unable to restore CT 104 - command 'lxc-usernsexec -m u:0:100000:65536 -m g:0:100000:65536 -- /usr/bin/proxmox-backup-client restore '--crypt-mode=none' ct/100/2026-06-04T08:00:03Z root.pxar /var/lib/lxc/104/rootfs --allow-existing-dirs --repository backups@pbs!PVE@pbs00.nublab.ca:GlusterHDD' failed: exit code 255

It seems to be parsing the last two idmaps and thinking it needs to also idmap the restoration (even though it doesn't, because the ids in the filesystem should just be restored identically, the LXC mapping takes care of the rest)

If I run from the CLI by doing something like pct restore --storage GlusterSSD 105 PBSGlusterHDD:backup/ct/100/2026-06-04T08:00:03Z though, it works just fine!

Is this a bug? Am I missing something?

 

[fabian]

your last command listed does a restore as privileged container without any mappings at all..

 

[fabian]

"lxc.*" is only restored if the restore is done by root@pam for security reasons.

 

[kayson]

your last command listed does a restore as privileged container without any mappings at all..

I'm running it with sudo, but the resulting container has an identical config as to what was backed up? Its unprivileged. Or do you mean the restore operation's privilege?

I don't see how restoring a container's filesystem with idmapping would ever work. Unless maybe the backup was done with the reverse map?

 

[fabian]

ah right, if you do not set `unprivileged` for a restore it will use the value from the backup even in CLI.

using which login did you try the restore over the UI/API?

 

[kayson]

ah right, if you do not set `unprivileged` for a restore it will use the value from the backup even in CLI.

using which login did you try the restore over the UI/API?

I was using my own user which is from an OIDC realm. It has admin perms, but sounds like root@pam has something special? When I did the CLI I used sudo so presumably that gets the special root@pam stuff. For the GUI restore, I left the setting to use privilege from the backup (the container is unprivileged)

 

[fabian]

yes, the CLI tools are always running as root@pam. so that explains the difference - if you want to restore this container with idmaps you need to log in as root@pam on the UI as well.