Backup schlägt fehl, permission Denied

[neu5500]

Hallo,

ich möchte auf meinem Proxmox ein Backup einrichten. Das Backup soll zu meiner NAS übertragen werden.

1.
Ich habe auf meiner NAS NFS aktiviert und den Proxmox Host über eine IP-Adresse zugelassen.
Der User hat auch Admin Rechte.

2.
Auf dem Proxmox habe ich ein neues Storage über NFS eingebunden.

Ich habe dann als Test mal versucht einen Container zu sichern. Der leider dann laut Berechtigungen fehlschlägt. (Backup auf lokale Festplatte funktioniert ohne Probleme).

Hier die fehlermeldung:

INFO: starting new backup job: vzdump 100 --mode snapshot --remove 0 --storage Backup --compress zstd --node Proxmox
INFO: Starting Backup of VM 100 (lxc)
INFO: Backup started at 2020-08-23 20:22:22
INFO: status = running
INFO: CT Name: Pi-hole
INFO: including mount point rootfs ('/') in backup
INFO: mode failure - some volumes do not support snapshots
INFO: trying 'suspend' mode instead
INFO: backup mode: suspend
INFO: ionice priority: 7
INFO: CT Name: Pi-hole
INFO: including mount point rootfs ('/') in backup
INFO: temporary directory is on NFS, disabling xattr and acl support, consider configuring a local tmpdir via /etc/vzdump.conf
INFO: starting first sync /proc/12344/root/ to /mnt/pve/Backup/dump/vzdump-lxc-100-2020_08_23-20_22_22.tmp
INFO: first sync finished - transferred 949.32M bytes in 57s
INFO: suspending guest
INFO: starting final sync /proc/12344/root/ to /mnt/pve/Backup/dump/vzdump-lxc-100-2020_08_23-20_22_22.tmp
INFO: final sync finished - transferred 368.64K bytes in 3s
INFO: resuming guest
INFO: guest is online again after 3 seconds
INFO: creating vzdump archive '/mnt/pve/Backup/dump/vzdump-lxc-100-2020_08_23-20_22_22.tar.zst'
INFO: tar: ./var/cache/apt/archives/partial: Cannot open: Permission denied
INFO: tar: ./var/cache/lighttpd: Cannot open: Permission denied
INFO: tar: ./var/log/syslog: Cannot open: Permission denied
INFO: tar: ./var/log/mail.log: Cannot open: Permission denied
INFO: tar: ./var/log/auth.log: Cannot open: Permission denied
INFO: tar: ./var/log/lighttpd: Cannot open: Permission denied
INFO: tar: ./var/lib/apt/lists/partial: Cannot open: Permission denied
INFO: tar: ./var/lib/postfix/master.lock: Cannot open: Permission denied
INFO: tar: ./var/spool/rsyslog: Cannot open: Permission denied
INFO: tar: ./var/spool/postfix/incoming: Cannot open: Permission denied
INFO: tar: ./var/spool/postfix/flush: Cannot open: Permission denied
INFO: tar: ./var/spool/postfix/maildrop: Cannot open: Permission denied
INFO: tar: ./var/spool/postfix/saved: Cannot open: Permission denied
INFO: tar: ./var/spool/postfix/corrupt: Cannot open: Permission denied
INFO: tar: ./var/spool/postfix/deferred: Cannot open: Permission denied
INFO: tar: ./var/spool/postfix/defer: Cannot open: Permission denied
INFO: tar: ./var/spool/postfix/bounce: Cannot open: Permission denied
INFO: tar: ./var/spool/postfix/hold: Cannot open: Permission denied
INFO: tar: ./var/spool/postfix/trace: Cannot open: Permission denied
INFO: tar: ./var/spool/postfix/public: Cannot open: Permission denied
INFO: tar: ./var/spool/postfix/private: Cannot open: Permission denied
INFO: tar: ./var/spool/postfix/active: Cannot open: Permission denied
INFO: Total bytes written: 984852480 (940MiB, 41MiB/s)
INFO: tar: Exiting with failure status due to previous errors
ERROR: Backup of VM 100 failed - command 'set -o pipefail && lxc-usernsexec -m u:0:100000:65536 -m g:0:100000:65536 -- tar cpf - --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' --one-file-system '--warning=no-file-ignored' '--directory=/mnt/pve/Backup/dump/vzdump-lxc-100-2020_08_23-20_22_22.tmp' ./etc/vzdump/pct.conf ./etc/vzdump/pct.fw '--directory=/mnt/pve/Backup/dump/vzdump-lxc-100-2020_08_23-20_22_22.tmp' --no-anchored '--exclude=lost+found' --anchored '--exclude=./tmp/?*' '--exclude=./var/tmp/?*' '--exclude=./var/run/?*.pid' . | zstd --rsyncable '--threads=1' >/mnt/pve/Backup/dump/vzdump-lxc-100-2020_08_23-20_22_22.tar.dat' failed: exit code 2
INFO: Failed at 2020-08-23 20:23:59
INFO: Backup job finished with errors
TASK ERROR: job errors

Danke

 

[neu5500]

Ich habe in der zwischen Zeit mal ein Container als Unpriviligiert auf "no" gesetzt da ging es. Möchte aber aufgrund der Sicherheit auf das Feature nicht verzichten..

 

[Witker]

Hast du es gelöst
Du weißt ja Privilegierter .....

 

[fabian]

das problem ist das übliche (sh. forensuche) - der unprivilegierte user muss das backup schreiben können.. wenn der NFS share nur für den "echten" root user schreibbar ist, dann kann auch nur der ein backup machen.. alternative zum schreibbar machen: backup lokal machen, dann per hook auf den NFS storage schieben

 

[Witker]

alternative zum schreibbar machen: backup lokal machen, dann per hook auf den NFS storage schieben

Ok dann bitte fixen damit das "Out of the Box" funktioniert
mein Projekt ist nicht Proxmox vernünftig zum Laufen kriegen!

 

[fabian]

das geht nicht out-of-the box. du musst den storage so konfigurieren dass der backup prozess schreiben kann, das kann niemand machen außer du..

 

[Witker]

du musst den storage so konfigurieren dass der backup prozess schreiben kann,

Na also geht ja danke
Und dazu gibts sicher eine Anleitung Schritt für Schritt für Dummies

Ich helfe gerne mit den Screenshots aber bitte sagt mir halt was wo usw.

Habe hier versucht sowas anzufangen
https://forum.proxmox.com/threads/wowto-ordner-auf-synology-in-proxmox-als-storage-hinzufügen.81077/

50 Views keine Antwort- Fazit hängt schon beim 1. Schritt weil es eben keiner weis und einfach irgendwas konfiguriert
Das bringt dann 100erte Posts im Forum, die sich tot laufen.

Also bitte hinsetzen Synology konfigurieren bis es geht.
Dann bitte mir sagen ich mache dann gerne die Screenshots das es erledigt ist
Was mein Ihr?

 

[fabian]

Na also geht ja danke
Und dazu gibts sicher eine Anleitung Schritt für Schritt für Dummies

Ich helfe gerne mit den Screenshots aber bitte sagt mir halt was wo usw.

Habe hier versucht sowas anzufangen
https://forum.proxmox.com/threads/wowto-ordner-auf-synology-in-proxmox-als-storage-hinzufügen.81077/

50 Views keine Antwort- Fazit hängt schon beim 1. Schritt weil es eben keiner weis und einfach irgendwas konfiguriert
Das bringt dann 100erte Posts im Forum, die sich tot laufen.

Also bitte hinsetzen Synology konfigurieren bis es geht.
Dann bitte mir sagen ich mache dann gerne die Screenshots das es erledigt ist
Was mein Ihr?

so funktioniert das nicht (und im kommandoton schon gar nicht). wenn du interesse daran hast ein produkt vom hersteller XYZ zu konfigurieren und dabei hilfe brauchst, solltest du dich an den support von hersteller XYZ wenden. auf PVE seite ist hier nichts zu tun - der storage muss für den user "root" IM container schreibbar sein (diese info habe ich dir schon mehrfach in verschiedenen threads gegegeben), wie du das auf deinem netzwerk storage einstellst musst du wissen (oder alternativ der hersteller deines netzwerk storages).

ich werde nicht mehr auf die ewig gleichen fragen antworten solange nicht erkennbar ist, dass bereitschaft zu analyse & verstehen des problems erkennbar ist..

 

[Witker]

Views 2K no solution!
NO SUPPORT!
Terrible!
Marketing technically dramatically wrong approach!

What is this for?
Do you already have a Commercial Support Subscription? - If not, Buy now and read the documentation

Do you really think you can get Someone to buy one after This?

 

[showiproute]

Ich muss hier dem Moderator Recht geben: Wenn man keine Ahnung von dem hat, mit dem man arbeitet und einfach nur eine Art "One-Click-Setup" möchte, an dem man gar nicht groß herum schrauben muss, dann wäre ein hosted-service oder ein externer Dienstleister, der das wunschgemäß einrichtet, der korrekte Weg.

Was nicht geht ist, dass man hier einfach den Moderatoren/Proxmox-Admins im Imperativ kundtut, was sie einem selbst einrichten sollen.

 

[Witker]

Ja Stimmt!

oguz​

Hat mich aufgeklärt
Hatte total falsche Erwartungen an das Forum hier.
Mein Schuld!
Entschuldigung!

LG
Witzker

 

[Eistee]

Hallo,
ich habe mit dem folgenden Befehl eine Freigabe von meinem NAS eingebunden um dort Backups meiner Container zu machen:

pvesm add cifs Backup --server 192.168.178.3 --share Backup --username abc --password xxx --path /mnt/Backup --content backup

Ich kann nun das Backup starten aber laufe auf das gleiche Problem. Der Benutzer den ich angegeben habe um auf die Freigabe zuzugreifen hat volle Rechte dort alles zu tun was über cifs möglich ist. Daher nun die Frage was ich tun muss.

LOG:

INFO: starting new backup job: vzdump 905 --storage Backup --remove 0 --node pve --notes-template '{{guestname}}' --mode snapshot --compress zstd
INFO: filesystem type on dumpdir is 'cifs' -using /var/tmp/vzdumptmp1468115_905 for temporary files
INFO: Starting Backup of VM 905 (lxc)
INFO: Backup started at 2022-09-07 19:39:02
INFO: status = running
INFO: CT Name: iobroker
INFO: including mount point rootfs ('/') in backup
INFO: backup mode: snapshot
INFO: ionice priority: 7
INFO: create storage snapshot 'vzdump'
INFO: creating vzdump archive '/mnt/Backup/dump/vzdump-lxc-905-2022_09_07-19_39_02.tar.zst'
INFO: tar: ./var/lib/private: Cannot open: Permission denied
INFO: tar: ./var/cache/private: Cannot open: Permission denied
INFO: tar: ./var/log/mail.err: Cannot open: Permission denied
INFO: tar: ./var/log/btmp: Cannot open: Permission denied
INFO: tar: ./var/log/private: Cannot open: Permission denied
INFO: Total bytes written: 22446827520 (21GiB, 34MiB/s)
INFO: tar: Exiting with failure status due to previous errors
INFO: cleanup temporary 'vzdump' snapshot
ERROR: Backup of VM 905 failed - command 'set -o pipefail && lxc-usernsexec -m u:0:100000:65536 -m g:0:100000:65536 -- tar cpf - --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' --one-file-system '--warning=no-file-ignored' '--directory=/var/tmp/vzdumptmp1468115_905' ./etc/vzdump/pct.conf ./etc/vzdump/pct.fw '--directory=/mnt/vzsnap0' --no-anchored '--exclude=lost+found' --anchored '--exclude=./tmp/?*' '--exclude=./var/tmp/?*' '--exclude=./var/run/?*.pid' ./ | zstd --rsyncable '--threads=1' >/mnt/Backup/dump/vzdump-lxc-905-2022_09_07-19_39_02.tar.dat' failed: exit code 2
INFO: Failed at 2022-09-07 19:49:57
INFO: Backup job finished with errors
TASK ERROR: job errors

LG Alina

 

[fabian]

nachschauen welche permissions die ordner haben, die nicht lesbar sind (z.b. mit stat)

 

[Eistee]

Im Container läuft eigentlich nur ein debian und iobroker da ist nix spezielles sonst konfiguriert.

  File: /var/lib/private
  Size: 2               Blocks: 1          IO Block: 512    directory
Device: 30h/48d Inode: 25348       Links: 2
Access: (0700/drwx------)  Uid: (65534/  nobody)   Gid: (65534/ nogroup)
Access: 2022-08-05 23:22:45.735835262 +0200
Modify: 2022-02-09 17:42:13.835023146 +0100
Change: 2022-09-07 18:50:46.094879624 +0200
 Birth: 2022-02-09 17:42:13.835023146 +0100


  File: /var/cache/private
  Size: 2               Blocks: 1          IO Block: 512    directory
Device: 30h/48d Inode: 25350       Links: 2
Access: (0700/drwx------)  Uid: (65534/  nobody)   Gid: (65534/ nogroup)
Access: 2022-08-05 23:22:45.735835262 +0200
Modify: 2022-02-09 17:42:13.835023146 +0100
Change: 2022-09-07 18:50:46.094879624 +0200
 Birth: 2022-02-09 17:42:13.835023146 +0100


  File: /var/log/mail.err
  Size: 204             Blocks: 9          IO Block: 512    regular file
Device: 30h/48d Inode: 444810      Links: 1
Access: (0640/-rw-r-----)  Uid: (65534/  nobody)   Gid: (65534/ nogroup)
Access: 2022-09-07 18:50:48.378914693 +0200
Modify: 2022-09-07 18:50:49.366929863 +0200
Change: 2022-09-07 18:50:49.366929863 +0200
 Birth: 2022-09-07 18:50:48.378914693 +0200


  File: /var/log/btmp
  Size: 0               Blocks: 1          IO Block: 131072 regular empty file
Device: 30h/48d Inode: 389256      Links: 1
Access: (0660/-rw-rw----)  Uid: (65534/  nobody)   Gid: (65534/ nogroup)
Access: 2022-09-01 00:00:15.213472748 +0200
Modify: 2022-09-01 00:00:15.213472748 +0200
Change: 2022-09-07 18:50:46.094879624 +0200
 Birth: 2022-09-01 00:00:15.213472748 +0200


  File: /var/log/private
  Size: 2               Blocks: 1          IO Block: 512    directory
Device: 30h/48d Inode: 25349       Links: 2
Access: (0700/drwx------)  Uid: (65534/  nobody)   Gid: (65534/ nogroup)
Access: 2022-08-05 23:23:01.564049421 +0200
Modify: 2022-02-09 17:42:13.835023146 +0100
Change: 2022-09-07 18:50:46.094879624 +0200
 Birth: 2022-02-09 17:42:13.835023146 +0100

 

[fabian]

kannst du die permissions nochmal von hypervisor seite aus dumpen? also pct mount .. und dann stat auf host seite (und dann wieder pct unmount ...

 

[Eistee]

Da sieht das ganze so aus:

  File: /var/lib/lxc/905/rootfs/var/lib/private
  Size: 2               Blocks: 1          IO Block: 512    directory
Device: 2fh/47d Inode: 25348       Links: 2
Access: (0700/drwx------)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2022-08-05 23:22:45.735835262 +0200
Modify: 2022-02-09 17:42:13.835023146 +0100
Change: 2022-09-07 18:50:46.094879624 +0200
 Birth: 2022-02-09 17:42:13.835023146 +0100


  File: /var/lib/lxc/905/rootfs/var/cache/private
  Size: 2               Blocks: 1          IO Block: 512    directory
Device: 2fh/47d Inode: 25350       Links: 2
Access: (0700/drwx------)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2022-08-05 23:22:45.735835262 +0200
Modify: 2022-02-09 17:42:13.835023146 +0100
Change: 2022-09-07 18:50:46.094879624 +0200
 Birth: 2022-02-09 17:42:13.835023146 +0100


  File: /var/lib/lxc/905/rootfs/var/log/mail.err
  Size: 204             Blocks: 9          IO Block: 512    regular file
Device: 2fh/47d Inode: 444810      Links: 1
Access: (0640/-rw-r-----)  Uid: (    0/    root)   Gid: (    4/     adm)
Access: 2022-09-07 18:50:48.378914693 +0200
Modify: 2022-09-07 18:50:49.366929863 +0200
Change: 2022-09-07 18:50:49.366929863 +0200
 Birth: 2022-09-07 18:50:48.378914693 +0200


  File: /var/lib/lxc/905/rootfs/var/log/btmp
  Size: 0               Blocks: 1          IO Block: 512    regular empty file
Device: 2fh/47d Inode: 389256      Links: 1
Access: (0660/-rw-rw----)  Uid: (    0/    root)   Gid: (   43/    utmp)
Access: 2022-09-01 00:00:15.213472748 +0200
Modify: 2022-09-01 00:00:15.213472748 +0200
Change: 2022-09-07 18:50:46.094879624 +0200
 Birth: 2022-09-01 00:00:15.213472748 +0200


  File: /var/lib/lxc/905/rootfs/var/log/private
  Size: 2               Blocks: 1          IO Block: 512    directory
Device: 2fh/47d Inode: 25349       Links: 2
Access: (0700/drwx------)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2022-08-05 23:23:01.564049421 +0200
Modify: 2022-02-09 17:42:13.835023146 +0100
Change: 2022-09-07 18:50:46.094879624 +0200
 Birth: 2022-02-09 17:42:13.835023146 +0100

 

[fabian]

und hier haben wir das problem - der container ist unprivilegiert, diese ordner/files gehoeren aber user und group vom host, daher koennen die aus container sicht (so wie das backup laeuft) nicht gesichert werden.

die file ownership laesst sich vom host aus korrigieren - im container sollten alle user um "100000" verschoben sein. also user root = 0 wird dann zu user root = 100000, group root = 0 wird zu group root = 100000 (d.h. zum beispiel bei /var/lib/private dann chown 100000 /var/lib/lxc/905/rootfs/var/lib/private). group admin = 4 wird dann zu 100004, utmp = 43 zu 100043. hoffe das hilft weiter - in den ordnern befinden sich eventuell noch mehr unterordner/files mit falscher ownership, die muessen auch entsprechend korrigiert werden.

wie das ganze passiert ist kann ich dir nicht sagen - kaputtest template zur erstellung verwendet, irgendwann mal von host seite sachen reinkopiert, manuell versucht von unprivilegiert auf privilegiert zu wechseln, ...?

 

[sdettmer]

Ich schreibe hier vor allem, weil Google bei mir diesen Thread als TOP #1 Treffer anzeigt, er mir aber nicht geholfen hat, im Gegenteil.
Daher schreibe ich hier meine Beobachtungen, in der Hoffnung, dass es anderen über Google kommenden hilf.

Ich hatte gerade augenscheinlich das gleiche Problem, allerdings im Image (Container file system) korrekte IDs.

Kurz:
Mir hat Proxmox Unprivileged Container Backup failed, Permission denied geholfen:

echo "tmpdir: /tmp" >> /etc/vzdump.conf

.
Damit liegt die rsync-Kopie nicht auf NFS und das tar funktioniert (unten dazu Details).

Wäre es nicht geschickter, gleich im echten Container tar zu machen (statt rsync in tmp und dann tar von tmp)?

Bei mir lag es jedenfalls nicht an falschen IDs im Container, sondern ich glaube, das könnte ein grundsätzliches Problem mit lxc UID mapping bei NFS sein.

Nun ausführlich.

Hintergrundinfos:
Ich habe ein Backup zurückgesichert. Möglicherweise war das von einem priviligierten Container, der rückgesicherte ist es jedenfalls nicht.
Dabei entstand ein image (vm-100-disk-0.raw) auf dem NAS (ursprünglich war das bestimmt ein lokales ZFS dataset und kein volume). Vermutlich habe ich beim Rücksichern was falsch eingestellt. Das alles habe ich aber zunächst überhaupt nicht bemerkt (schließlich ging der Container ).
Ich habe den cluster inzwischen neu aufgesetzt. Das backup ist auch mit einer älteren Version gemacht wurden (gesichert ca. 7.2, rückgesichert 7.4).

Heute stellte ich fest, dass neuerliche Backups nicht von diesem restored container nicht gehen: das permission denied des OP.

Nach einigem Suchen habe ich in /etc/vzdump.conf tmpdir=/tmp gesetzt nach Proxmox Unprivileged Container Backup failed, Permission denied

Ich habe das container image über loop gemounted und sah wie erwartet "hohe" UIDs, beispielsweise:

root@labhen197-101: # mount /mnt/pve/cnas1/images/100/vm-100-disk-0.raw -o loop /mnt/tmp/
root@labhen197-101: # ls -ld /mnt/tmp/home/ /mnt/tmp/home/jenkins-admin/
drwxr-xr-x 3 100000 100000 4096 Apr 28  2021 /mnt/tmp/home/
drwxr-xr-x 5 101000 101000 4096 Apr 28  2021 /mnt/tmp/home/jenkins-admin/

die entstanden (durch rsync) genau so im NFS:

drwxr-xr-x 18 100000 100000 4096 Jun 29 19:22 /mnt/pve/cnas1/dump/vzdump-lxc-100-2023_06_30-15_42_43.tmp
drwx------ 2 101000 101000 4096 Apr 28  2021 /mnt/pve/cnas1/dump/vzdump-lxc-100-2023_06_30-15_42_43.tmp/home/jenkins-admin/.ssh/

bzw. nach der Änderung vzdump tmpdir:

root@labhen197-101:/tmp# ls -ld vzdumptmp2013353_100/home/ vzdumptmp2013353_100/home/jenkins-admin/
drwxr-xr-x 3 100000 100000 4096 Apr 28  2021 vzdumptmp2013353_100/home/
drwxr-xr-x 5 101000 101000 4096 Apr 28  2021 vzdumptmp2013353_100/home/jenkins-admin/
root@labhen197-101:/tmp#

im container mit ID 100 gibt es einen user "jenkins-admin" mit UID 1000. Meines Verständnisses nach sind die UIDs wie 101000 damit korrekt.

Ich habe mit ps geguckt, was eigentlich passiert.
Beim Backup wird mit echtem root ein rsync in das tmpdir gemacht:

root     2017058  2.5  0.0  85276 17972 ?        D    16:31   0:00 rsync --stats -h -X -A --numeric-ids -aH --delete --no-whole-file --sparse --one-file-system --relative --exclude=/tmp/?* --exclude=/var/tmp/?* --exclude=/var/run/?*.pid /proc/131896/root//./ /tmp/vzdumptmp2017052_100/

Und die Kopie dann mit tar gepackt. Das "Problem" ist dann, dass das tar über einen Container als user 100000 läuft:

root     2017756  0.0  0.0   3896  2736 ?        S    16:32   0:00 /bin/bash -c set -o pipefail && lxc-usernsexec -m u:0:100000:65536 -m g:0:100000:65536 -- tar cpf - --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' --one-file-system '--warning=no-file-ignored' '--directory=/tmp/vzdumptmp2017052_100/' ./etc/vzdump/pct.conf ./etc/vzdump/pct.fw '--directory=/tmp/vzdumptmp2017052_100/' --no-anchored '--exclude=lost+found' --anchored '--exclude=./tmp/?*' '--exclude=./var/tmp/?*' '--exclude=./var/run/?*.pid' . | zstd --rsyncable '--threads=1' >/mnt/pve/cnas1/dump/vzdump-lxc-100-2023_06_30-16_31_27.tar.dat
root     2017757  0.0  0.0   8320  3496 ?        S    16:32   0:00 lxc-usernsexec -m u:0:100000:65536 -m g:0:100000:65536 -- tar cpf - --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 --one-file-system --warning=no-file-ignored --directory=/tmp/vzdumptmp2017052_100/ ./etc/vzdump/pct.conf ./etc/vzdump/pct.fw --directory=/tmp/vzdumptmp2017052_100/ --no-anchored --exclude=lost+found --anchored --exclude=./tmp/?* --exclude=./var/tmp/?* --exclude=./var/run/?*.pid .
root     2017758 29.0  0.1 128316 38632 ?        Sl   16:32   0:00 zstd --rsyncable --threads=1
100000   2017759 26.0  0.0   5900  4360 ?        R    16:32   0:00 tar cpf - --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 --one-file-system --warning=no-file-ignored --directory=/tmp/vzdumptmp2017052_100/ ./etc/vzdump/pct.conf ./etc/vzdump/pct.fw --directory=/tmp/vzdumptmp2017052_100/ --no-anchored --exclude=lost+found --anchored --exclude=./tmp/?* --exclude=./var/tmp/?* --exclude=./var/run/?*.pid .

und das UID mapping scheme über NFS augenscheinlich nicht richtig funktioniert, denn auf NFS kann das tar die kopierten Dateien nicht lesen:

2023-06-30 15:47:08 INFO: tar: ./var/lib/jenkins/identity.key.enc: Cannot open: Permission denied
2023-06-30 15:47:09 INFO: tar: ./var/lib/jenkins/.ssh: Cannot open: Permission denied
2023-06-30 15:47:09 INFO: tar: ./var/lib/jenkins/secrets: Cannot open: Permission denied

Man sieht, dass der UID 10000 Prozess UID 10100 Dateien nicht lesen kann (UID 10000 Dateien aber schon).
Backup klappt aber für exakt die gleiche VM mit tmpdir=/tmp in vzdump.conf - Das scheint mir also ein grundsätzliches Problem bei NFS zu sein.
no_root_squash hilft nicht, da das tar gar nicht als root (UID 0) läuft. Ich habe als root auf der PVE node Shell die Dateien lesen können, die das tar nicht lesen konnte.
Ich habe das no_root_squash sogar getestet:

root@labhen197-101:/mnt/pve/cnas1/dump# touch uid0-file ; touch uid1000-file.tmp && chown 1000 uid1000-file.tmp && mv uid1000-file.tmp uid1000-file ; rm -f uid1000-file.tmp ; ls -ln uid*file
-rw-r--r-- 1    0 0 0 Jun 30 17:16 uid0-file
-rw-r--r-- 1 1000 0 0 Jun 30 17:16 uid1000-file
root@labhen197-101:/mnt/pve/cnas1/dump#

Das bringt mich zur Frage, warum überhaupt auf das NFS kopiert wird (bzw. ob das explizit gewollt oder eher ein Zufall/Seiteneffekt ist). Das rsync in das neue tmp directory is ja immer ein full sync und nie inkrementell, also sollte es nicht schneller als ein tar sein. Geht es im die ignore-Funktionen von rsync oder so? Die Behandlung von xattrs könnte auf vzdump tmp directories wie NFS oder einfachen Dateisystemen (hat noch jemand ext2?) auch problematisch sein. Auch kann lxc Einschränkungen bei ACLs machen (ich glaube, ZFS ACL kann man selbst in priviligiertem Container nicht setzen, daher kann Samba so ein mapping, um user.* statt security.* zu nehmen, was natürlich auch nicht ideal ist).

Wäre es nicht geschickter, gleich im echten Container tar zu machen (statt rsync in tmp und dann tar von tmp)?

 

[fabian]

bei containern gibts grundsaetzlich drei varianten:

snapshot
- erfordert support vom storage, es werden snapshots der mountpoints gemacht, gemounted, und dann wird von diesen gemounteten snapshots direkt das backup gezogen (mit tar/proxmox-backup-client)
- tar bzw. der client laufen dabei trotzdem im "container" user namespace, sonst stimmen die owner im backup nicht

suspend
- braucht keinen storage support, wird als "downgrade" automatisch gemacht wenn snapshot gewaehlt wurde, aber nicht unterstuetzt wird
- verwendet 2x rsync um eine kopie der daten anzulegen
-- 1x waehrend der container normal laeuft
-- 1x inkrementell waehrend der container eingefroren ist (konsistenz!)
- tar bzw. backup client sichern dann die temporaere kopie
- bei backup auf NFS sollte der temporaere pfad nicht auch am NFS liegen -> sonst werden die daten mehrfach uebers netzwerk geschoben
- rsync laeuft dabei als root vom host
- tar bzw. der client laufen dabei trotzdem im "container" user namespace, sonst stimmen die owner im backup nicht

stop
- erforder keinen storage support
- mountpoints werden gemounted, backup wird direkt gezogen
- tar bzw. der client laufen dabei trotzdem im "container" user namespace, sonst stimmen die owner im backup nicht

d.h. schreibzugriff fuer den container user aufs backup target im tar fall muss in allen drei faellen gegeben sein. NFS macht vor allem bei suspend probleme, wenn entweder root nicht schreiben oder der unprivilegierte user nicht lesen kann, oder ACLs nicht supported werden aber gesetzt sind.

 

[sdettmer]

- tar bzw. der client laufen dabei trotzdem im "container" user namespace, sonst stimmen die owner im backup nicht

Super, vielen Dank für die tolle Zusammenfassung / Übersicht!

Ahh ja klar, die owner stimmen nur im Container, da hätte ich auch selbst drauf kommen können - sonst könnte man ein Backup ja nur auf die gleiche Container ID restoren (das wäre ja ein Microsoft-Konzept SCNR).
Super danke!