Issues restoring unprivileged container

Requi

New Member
Aug 14, 2023
2
0
1
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:
Code:
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:
Code:
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:

Code:
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.
 
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.
 
Last edited:
  • Like
Reactions: AO554 and 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!
 
Last edited:
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.
 
  • Like
Reactions: Requi

About

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!