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

kayson

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

Code:
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

Code:
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?
 
your last command listed does a restore as privileged container without any mappings at all..
 
"lxc.*" is only restored if the restore is done by root@pam for security reasons.
 
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?