Issues restoring unprivileged container

[Requi]

My software raid just failed, but I still have backups of all the containers.
But I'm having issues restoring those containers due to the idmap failing.

Configuration:

arch: amd64
cores: 4
features: nesting=1
hostname: radarr
memory: 2048
mp0: /mnt/plex-media,mp=/plex-media
net0: name=eth0,bridge=vmbr0,firewall=1,hwaddr=7E:3C:B1:B6:46:46,ip=dhcp,type=veth
onboot: 1
ostype: debian
rootfs: local:100/vm-100-disk-0.raw,size=32G
swap: 0
unprivileged: 1
lxc.idmap: u 0 100000 1000
lxc.idmap: g 0 100000 1000
lxc.idmap: u 1000 1000 1
lxc.idmap: g 1000 1000 1
lxc.idmap: u 1001 101001 64530
lxc.idmap: g 1001 101001 64530
lxc.idmap: g 65534 165534 1

Restore log:

recovering backed-up configuration from 'local:backup/vzdump-lxc-100-2023_08_05-21_00_00.tar.zst'
Formatting '/var/lib/vz/images/100/vm-100-disk-0.raw', fmt=raw size=34359738368 preallocation=off
Creating filesystem with 8388608 4k blocks and 2097152 inodes
Filesystem UUID: c10b590b-8180-4838-ba17-d3e9fa18f50f
Superblock backups stored on blocks:
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
    4096000, 7962624
restoring 'local:backup/vzdump-lxc-100-2023_08_05-21_00_00.tar.zst' now..
extracting archive '/var/lib/vz/dump/vzdump-lxc-100-2023_08_05-21_00_00.tar.zst'
tar: ./etc/vzdump/pct.conf: Cannot change ownership to uid 65534, gid 65534: Invalid argument
tar: ./etc/vzdump/pct.fw: Cannot change ownership to uid 65534, gid 65534: Invalid argument
tar: ./proc: Cannot change ownership to uid 65534, gid 65534: Invalid argument
tar: ./sys: Cannot change ownership to uid 65534, gid 65534: Invalid argument
Total bytes read: 9326305280 (8.7GiB, 787MiB/s)
tar: Exiting with failure status due to previous errors

My /etc/subuid and /etc/subgid look like this:

root:100000:65536
root:1000:1

I unfortunately don't have a backup of the subuid/gid files, so I'm not sure if I'm missing something in there.

 

[fweber]

Hi, I think the issue is that the backup file contains certain files owned by 65534:65534 (nobody:nobody), but the custom ID mapping only has an entry for gid 65534 and is missing an entry for uid 65534. The restore process starts tar in a user namespace with the given ID mapping, and tar tries to change ownership of those files to 65534:65534, which fails because the uid 65534 is not mapped.

Unfortunately the mapping is defined within the backup file itself, in file ./etc/vzdump/pct.conf, so to fix the mapping by adding an entry for uid 65534, you'd have to unpack the archive, change the mapping and pack a new archive. Alternatively, you can try the following workaround: Restore the container not as root, but as a non-root user (create a user with the PVEAdmin role, log in as this user and restore the backup). As the user is non-root, PVE will ignore the custom ID mapping on restore (and write a warning to the task log). As the mapping is ignored, the restore should work without errors. However, you'll have the re-add the mapping (with a mapping for uid 65534) to the config file afterwards.

 

[Requi]

I'll try the non-root user solution later.

I'd be completely fine with removing before and redoing the idmaps after restoring the containers.
I attempted to change the pct.conf, but after packing it back into a .tar.zst the web interface told me it can't find any configuration for the backup.
Not sure if I did something wrong. I used tar -I zstd to create it again.
(On second thought I think I know why it didn't work. I did tar folder instead of tar . I'll retry this later as well)

Appreciate the response. Thank you!

 

[fweber]

I'd be completely fine with removing before and redoing the idmaps after restoring the containers.
I attempted to change the pct.conf, but after packing it back into a .tar.zst the web interface told me it can't find any configuration for the backup.
Not sure if I did something wrong. I used tar -I zstd to create it again.

I encountered the same issue -- try using tar . instead of tar * when re-packing, otherwise the paths apparently end up being wrong in the archive.