Backup / Restore funktioniert nicht mit priviligerten LXC

KLez

New Member
Mar 7, 2020
12
2
3
43
Hallo,

Ich habe das Problem, dass die Backup / Restore Funktion bei mir mit priviligierten LXC Containern nicht funktioniert. Kompression an / aus macht keinen Unterschied. Beim zurückspielen erscheinen immer die folgenden Fehlermeldungn und es wird letzendlich mit Exit Code 2 abgebrochen:

Code:
tar: bin/zmore: Cannot change ownership to uid 100000, gid 100000: Invalid argument
tar: bin/systemd-escape: Cannot change ownership to uid 100000, gid 100000: Invalid argument
tar: bin/kmod: Cannot change ownership to uid 100000, gid 100000: Invalid argument
tar: bin/ypdomainname: Cannot change ownership to uid 100000, gid 100000: Invalid argument
tar: bin/bzfgrep: Cannot change ownership to uid 100000, gid 100000: Invalid argument
tar: bin/zcat: Cannot change ownership to uid 100000, gid 100000: Invalid argument
tar: bin/fgrep: Cannot change ownership to uid 100000, gid 100000: Invalid argument
tar: bin/bzmore: Cannot change ownership to uid 100000, gid 100000: Invalid argument
......
usw. usw.

Eigentlich wäre das für mich kein größeres Problem, da ich nur unpriviligierte Container verwende, aber ich wüsste gerne woran das liegt. Ist das ein Bug?
Ich verwende Proxmox VE 6.1 mit den neuesten Updates.
 
Last edited:
Nimmst Du auch den Haken "unprivileged Container" raus beim wiederherstellen (restore)

Man kann mit Backup Restore auf beliebigen Privilegien-Modus wechseln, wenn nicht ist das ein Bug - den dass ist unser offizieller weg einen CT von Privilegiert auf Unprivilegiert, oder umgekehrt, zu wechseln.
 
  • Like
Reactions: CoolTux
Ich habe es eben getestet. Es geht nicht.

Code:
/dev/rbd6
mke2fs 1.44.5 (15-Dec-2018)
Discarding device blocks:   4096/786432             done                           
Creating filesystem with 786432 4k blocks and 196608 inodes
Filesystem UUID: 9d50bbdd-194e-4d21-8bbc-484b26ccf29b
Superblock backups stored on blocks:
    32768, 98304, 163840, 229376, 294912

Allocating group tables:  0/24     done                           
Writing inode tables:  0/24     done                           
Creating journal (16384 blocks): done
Multiple mount protection is enabled with update interval 5 seconds.
Writing superblocks and filesystem accounting information:  0/24     done

extracting archive '/mnt/pve/backup/dump/vzdump-lxc-303-2020_03_09-11_49_30.tar.gz'
tar: ./var/spool/postfix/dev/urandom: Cannot mknod: Operation not permitted
tar: ./var/spool/postfix/dev/random: Cannot mknod: Operation not permitted
Total bytes read: 1322588160 (1.3GiB, 66MiB/s)
tar: Exiting with failure status due to previous errors
Removing image: 1% complete...
Removing image: 2% complete...
Removing image: 3% complete...
Removing image: 4% complete...
Removing image: 5% complete...
Removing image: 6% complete...
Removing image: 7% complete...
...
Removing image: 98% complete...
Removing image: 99% complete...
Removing image: 100% complete...done.
TASK ERROR: unable to restore CT 303 - command 'lxc-usernsexec -m u:0:100000:65536 -m g:0:100000:65536 -- tar xpf - -z --totals --one-file-system -p --sparse --numeric-owner --acls --xattrs '--xattrs-include=user.*' '--xattrs-include=security.capability' '--warning=no-file-ignored' '--warning=no-xattr-write' -C /var/lib/lxc/303/rootfs --skip-old-files --anchored --exclude './dev/*'' failed: exit code 2

Was habe ich gemacht?
Ich habe einen priviligierten Cotainer mittels Turnkey Template (Drupal 8) angelegt und diesen dann gesichert (Backup).
Danach habe ich einen Restore gemacht und nicht den Haken raus genommen bei "unpriviligierter Container"

Was man natürlich machen kann ist das Backup entpacken und die beiden Files löschen. Dann würde es gehen. Aber dann gibt es wieder andere Probleme, zuweilen mit der Anwendung. Ich hatte es beim Apache zum Beispiel.


Grüße
 
Nimmst Du auch den Haken "unprivileged Container" raus beim wiederherstellen (restore)
Soweit ich weiß sollte das keinen Unterschied machen. Wie t.lamprecht schon sagte, ist das sogar der offizielle Weg.

Mir ist allerdings gestern abend noch aufgefallen, dass mein Container (mit dem ich das Backup / Restore getestet habe) scheinbar schon nach dem erstellen eine "Macke" hatte. Die Dateien und Ordner in / gehören dem User "100000" anstatt "root". Warum das so ist: Keine Ahnung. War schon nach dem erstellen so. Muß ich heute abend nochmal etwas genauer untersuchen.
 
Ich habe es eben getestet. Es geht nicht.

Code:
/dev/rbd6
mke2fs 1.44.5 (15-Dec-2018)
Discarding device blocks:   4096/786432             done                          
Creating filesystem with 786432 4k blocks and 196608 inodes
Filesystem UUID: 9d50bbdd-194e-4d21-8bbc-484b26ccf29b
Superblock backups stored on blocks:
    32768, 98304, 163840, 229376, 294912

Allocating group tables:  0/24     done                          
Writing inode tables:  0/24     done                          
Creating journal (16384 blocks): done
Multiple mount protection is enabled with update interval 5 seconds.
Writing superblocks and filesystem accounting information:  0/24     done

extracting archive '/mnt/pve/backup/dump/vzdump-lxc-303-2020_03_09-11_49_30.tar.gz'
tar: ./var/spool/postfix/dev/urandom: Cannot mknod: Operation not permitted
tar: ./var/spool/postfix/dev/random: Cannot mknod: Operation not permitted
Total bytes read: 1322588160 (1.3GiB, 66MiB/s)
tar: Exiting with failure status due to previous errors
Removing image: 1% complete...
Removing image: 2% complete...
Removing image: 3% complete...
Removing image: 4% complete...
Removing image: 5% complete...
Removing image: 6% complete...
Removing image: 7% complete...
...
Removing image: 98% complete...
Removing image: 99% complete...
Removing image: 100% complete...done.
TASK ERROR: unable to restore CT 303 - command 'lxc-usernsexec -m u:0:100000:65536 -m g:0:100000:65536 -- tar xpf - -z --totals --one-file-system -p --sparse --numeric-owner --acls --xattrs '--xattrs-include=user.*' '--xattrs-include=security.capability' '--warning=no-file-ignored' '--warning=no-xattr-write' -C /var/lib/lxc/303/rootfs --skip-old-files --anchored --exclude './dev/*'' failed: exit code 2

Was habe ich gemacht?
Ich habe einen priviligierten Cotainer mittels Turnkey Template (Drupal 8) angelegt und diesen dann gesichert (Backup).
Danach habe ich einen Restore gemacht und nicht den Haken raus genommen bei "unpriviligierter Container"

Was man natürlich machen kann ist das Backup entpacken und die beiden Files löschen. Dann würde es gehen. Aber dann gibt es wieder andere Probleme, zuweilen mit der Anwendung. Ich hatte es beim Apache zum Beispiel.


Grüße

Gibt es mittlerweile einen Workaround dafür? Ich stehe vor dem gleichen Problem.
Blöde Frage: Wie kann man ein LXC-backup entpacken? Einfach tar -xvzf /pfad/zum/backup.tar.gz?

Im moment stehe ich vor dem Problem, dass ich das Backup auf meinem lokalen Storage gemacht habe, aber nicht weiß wo das in proxmox gemountet wird?
 
Je nach dem wie das Backup angelegt wurde kann man es einfach mit tar entpacken. Was ist denn genau Dein Problem?
Schau mal unter Datacenter -> Storage da sollte zu sehen sein wo es wie gemountet ist.
 
Je nach dem wie das Backup angelegt wurde kann man es einfach mit tar entpacken. Was ist denn genau Dein Problem?
Schau mal unter Datacenter -> Storage da sollte zu sehen sein wo es wie gemountet ist.
Hab das Backup in /var/lib/vz/dump gefunden. Man muss ja nur mal kurz in in das Protokoll des Wiederherstellungsrozesses schauen.
Entpacke jetzt das Backup und versuche es dann durch löschen der zwei device-nodes wieder zu packen und wiederherzustellen.
 
Je nach dem wie das Backup angelegt wurde kann man es einfach mit tar entpacken. Was ist denn genau Dein Problem?
Schau mal unter Datacenter -> Storage da sollte zu sehen sein wo es wie gemountet ist.
Naja, ich dachte, dass ich das wahrscheinlich via SSH/Terminal entpacken muss. Hier weiß ich nicht, wo im proxmox Dateisystem das
 
Hab jetzt mein Backup modifizieren können. Habe es wie folgt bearbeitet

Bash:
# entpacken
tar --use-compress-program=unzstd -xvf pfad-zum-backup.tar.zst --directory ausgabeordner

# die "fehlerhaften" Dateien löschen
cd var/spool/postfix/dev/
rm urandom random

# Im root ordner folgenden Befehl zum wieder verpacken ausführen
tar --zstd -cvf ../name-des-modifizierten-backups.tar.zst .

Beim Restore über die Proxox-GUI konnte ich den LXC-Container im privileged modus wiederherstellen.
 
  • Like
Reactions: CoolTux

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!