[SOLVED] Backup auf NFS klappt bei einigen LXC nicht (mehr) - Grund war: unprivileged LXC Container

[sixpack.de]

Hi,

ich habe ein seltsames Problem und weiss nicht weiter:
VE: 5.4-13
2 VMs
5 LXCs
NFS zur Sicherung (Snapshot) -> Synology NAS

Die beiden VMs und drei der 5 LXCs sichern problemlos auf das NAS
die beiden (neuesten) LXCs nicht...

Log (eine durchlaufende und eine nicht durchlaufende):

108: 2020-02-17 02:06:20 INFO: Starting Backup of VM 108 (lxc)
108: 2020-02-17 02:06:20 INFO: status = running
108: 2020-02-17 02:06:20 INFO: CT Name: unifi
108: 2020-02-17 02:06:20 INFO: backup mode: snapshot
108: 2020-02-17 02:06:20 INFO: ionice priority: 7
108: 2020-02-17 02:06:20 INFO: create storage snapshot 'vzdump'
108: 2020-02-17 02:06:22 INFO: creating archive '/mnt/pve/proxmox-syn/dump/vzdump-lxc-108-2020_02_17-02_06_20.tar.lzo'
108: 2020-02-17 02:07:33 INFO: Total bytes written: 7586693120 (7.1GiB, 103MiB/s)
108: 2020-02-17 02:07:33 INFO: archive file size: 1.90GB
108: 2020-02-17 02:07:33 INFO: delete old backup '/mnt/pve/proxmox-syn/dump/vzdump-lxc-108-2020_02_06-02_04_26.tar.lzo'
108: 2020-02-17 02:07:34 INFO: remove vzdump snapshot
108: 2020-02-17 02:07:34 INFO: Finished Backup of VM 108 (00:01:14)

111: 2020-02-17 02:07:34 INFO: Starting Backup of VM 111 (lxc)
111: 2020-02-17 02:07:34 INFO: status = running
111: 2020-02-17 02:07:34 INFO: CT Name: IOBroker
111: 2020-02-17 02:07:34 INFO: backup mode: snapshot
111: 2020-02-17 02:07:34 INFO: ionice priority: 7
111: 2020-02-17 02:07:34 INFO: create storage snapshot 'vzdump'
111: 2020-02-17 02:07:34 INFO: creating archive '/mnt/pve/proxmox-syn/dump/vzdump-lxc-111-2020_02_17-02_07_34.tar.lzo'
111: 2020-02-17 02:07:34 INFO: tar: /mnt/pve/proxmox-syn/dump/vzdump-lxc-111-2020_02_17-02_07_34.tmp: Cannot open: Permission denied
111: 2020-02-17 02:07:34 INFO: tar: Error is not recoverable: exiting now
111: 2020-02-17 02:07:34 INFO: remove vzdump snapshot
111: 2020-02-17 02:07:35 ERROR: Backup of VM 111 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/proxmox-syn/dump/vzdump-lxc-111-2020_02_17-02_07_34.tmp' ./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' ./ | lzop >/mnt/pve/proxmox-syn/dump/vzdump-lxc-111-2020_02_17-02_07_34.tar.dat' failed: exit code 2

Ich weiss ehrlich gesagt nicht mehr weiter.

Lokal können die beiden LXCs backups ablegen, was für ein rechte Problem spricht. Das macht aber auch keinen Sinn ...

Hat irgendwer eine Idee????

Danke und Gruß aus Köln,

Jan

 

[Stoiko Ivanov]

bitte mal die config von einem container posten, bei dem das backup funktioniert und einem bei dem es nicht geht.

meine erste Vermutung: die funktionierenden sind privileged, die neueren, bei denen es nicht geht unprivileged (das default hat sich vor längerem mal geändert) - wenn das der unterschied ist:
bei unprivileged Containern wird das backup im usernamespace des containers gemacht - sprich root drinnen ist user 100000 draußen, und dieser muss auf den NFS share schreiben können dürfen.

Ich hoffe das hilft!

 

[sixpack.de]

Hi,

Danke, das ist auf jeden Fall der Unterschied ...

man kann die Container nicht so ohne weiteres zu privileged um-editieren habe ich grade gemerkt ... mal sehen wie ich den User effizient in das Synology bekomme...

UPDATE: YEP das wars

Gruß,

Jan

 

[tony blue]

Hallo,

wenn in der /etc/vzdump.conf die Variable


# vzdump default settings
#tmpdir: DIR
tmpdir: /tmp

gesetzt wird funktionieren bei mir die Backups wieder.

Der Tipp stammt von hier: https://www.bachmann-lan.de/proxmox-unprivileged-container-backup-failed-permission-denied/


-> Kann mir vielleicht jemand sagen, wohin die standardmäßig gesetzte Variable "DIR" zeigt? Damit könnte ich dann die Rechte des Verzeichnisses anpassen und die /etc/vzdump.conf unverändert lassen.

-> Mit unprivilegierten LXC Contrainern treten bei mir noch weitere (ungelöste) Probleme auf (clone + docker läuft nicht). https://forum.proxmox.com/threads/l...ckup-clone-geht-nicht-mehr.66350/#post-298048

Vielleicht hat hierzu noch jemand eine Idee.

Vielen Dank!

Tony

 

[sixpack.de]

Hi,

nur damit das nicht falsch verstanden wird. Die Lösung ist NICHT die Container zu privilegieren, die Lösung ist dem User 100000 schreibrechte auf dem NFS share einzuräumen.

Ich muss mal schauen wo die Synology den Fehler hinloggt, das wäre am einfachsten gewesen (ich konnte nirgends sehen, welcher user versucht zu schreiben) Keine Änderungen am Proxmoxx, alles gut

Hat jemand einen Vorschlag für einen Syslog-Server ?
- für Dumme (i.e. mich)
- GUI
- nicht unter Windows, möglichst als fertiges LXC

Gruß,

Jan

 

[tony blue]

Kann mir jemand vielleicht noch was zum Inhalt der Variable DIR sagen?

-> Kann mir vielleicht jemand sagen, wohin die standardmäßig gesetzte Variable "DIR" zeigt? Damit könnte ich dann die Rechte des Verzeichnisses anpassen und die /etc/vzdump.conf unverändert lassen.

Vielen Dank!

Tony

 

[sixpack.de]

Kann mir jemand vielleicht noch was zum Inhalt der Variable DIR sagen?

Hi,

die zeigt auf dump --> /mnt/pve/proxmox-syn/dump/ in meinem fall (siehe log) wohin die bei Dir zeigt steht in Deinem Log.

Lösung:
Option A) Schreibrechte für den User 1000 auf dem Verzeichnis einräumen
Option B) Schreib-pfad auf ein Verzeichnis umbiegen in das alle User schreiben dürfen
Option C) Container auf priviligiert setzten

Ich habe A) gewählt, erschien mir am saubersten.

Guß,

Jan

 

[Witker]

Option A) Schreibrechte für den User 1000 auf dem Verzeichnis einräumen

Ich habe A) gewählt, erschien mir am saubersten.

Ja mir auch

Ich bin ein Newbie
wo muss Ich was machen
im Container oder auf der Synology?
Suche schon ewig nach dieser Lösung

 

[Dunuin]

Im privilegierten LXC kannst du unter Features "NFS" oder "CIFS" aktivieren und so das Mounten von Shares erlauben. Im unprivilegierten geht das nicht. Da musst du dann den Share direkt auf dem Host mounten, per Bind-Mount in den LXC durchreichen und das User-Mapping für den jeweiligen benutzer manuell setzen. Wenn da der User mit der UID 1000 auf dem Share schreibrechte hat, dann muss das so umgemappt werden, dass da der User mit der UID 1000 im LXC auch auf dem Host zu 1000 wird. Ansonsten ist dein User 1000 im LXC in Wirklichkeit der User 101000 auf dem Host und hat dann ja keine Rechte mehr für den Share. Wie man das macht steht hier.

 

[Witker]

Ich hab halt in die /etc/vzdump.conf
bei #tmpdir: DIR

tmpdir: /tmp​

reingeschrieben

Bisher konnte ich von allen meinen Containern damit jetzt Backups machen.

Im privilegierten LXC kannst du unter Features "NFS" oder "CIFS" aktivieren und so das Mounten von Shares erlauben. Im unprivilegierten geht das nicht. Da musst du dann den Share direkt auf dem Host mounten, per Bind-Mount in den LXC durchreichen und das User-Mapping für den jeweiligen benutzer manuell setzen. Wenn da der User mit der UID 1000 auf dem Share schreibrechte hat, dann muss das so umgemappt werden, dass da der User mit der UID 1000 im LXC auch auf dem Host zu 1000 wird. Ansonsten ist dein User 1000 im LXC in Wirklichkeit der User 101000 auf dem Host und hat dann ja keine Rechte mehr für den Share. Wie man das macht steht hier.

Welche Vorteile hat denn diese Lösung?

 

[Dunuin]

Wenn du einfach dem Share chmod 777 gibst, dann kommt da echt jeder ohne irgendeine Art von Authentifizierung an deine Daten. Da kann dann jedes Android-Smartphone von Gästen im WLAN mit Apps drauf, die sonst etwas an Spyware/Schadware drauf haben, die Daten in deinem Share lesen oder löschen. Viel Spaß wenn da mal Ransomware bei ist.
Wenn du das wie oben beschrieben machst, dann kannst du auch chmod 600 oder 640 nutzen und dann hat echt nur ein einziger User oder eine einzige Gruppe dort Zugriff und die Daten sind wesentlich sicherer. Außerdem sollte man nach Möglichkeit privilegierte LXCs vermeiden, besonders wenn die irgendwie vom Internet aus erreichbar sind, damit ein korrumpieter LXC nicht so einfach den ganzen Server übernehmen kann.

 

[Witker]

Vielen Dank!!

chmod 600 oder 640 nutzen

Was muss ich den da Wo eintragen?

 

[Dunuin]

Vielen Dank!!


Was muss ich den da Wo eintragen?

Lese-/Schreibrechte von dem Share musste du dort einstellen, was dir den Share bereitstellt. Also bei dir wohl das Synology-NAS. Wenn du SMB nutzt, dann kannst du beim Mounten auf Proxmox auch noch einmal UID, GID und Rechte angeben, wie Proxmox das dem System bereitstellen soll. Falls du NFS nutzt und nicht SMB, dann musst du noch gucken, ob da Synology auch irgendeine Art von Authentifizierung mit Nutzername/Passwort bietet. Im Normalfall führt NFS selbst keine Authentifizierung durch.
Wenn du den Share auf dem NAS dann so abgesichert hast, dass da nur noch ein User oder eine Gruppe mit Accountname + Passwort an den Share kommt, dann kannst du den Share direkt auf deinem Proxmox einbinden.
Die unprivilegieren LXCs sind sicherer weil besser isoliert, aber im unprivilegierten LXC darfst du keine Shares mounten. Deshalb muss der Share auf dem Proxmox-Host selbst und nicht direkt im LXC gemountet werden.
Um den Share vom Proxmox-Host dann per Bind-Mount mit User-Remapping in den LXC zu bekommen muss man das so machen wie hier in der Anleitung:
https://pve.proxmox.com/wiki/Unprivileged_LXC_containers

 

[Witker]

Ah!
Der NFS auf der Synology ist so freigegeben

bei den Usern ist gar nichts angehakt, wenn ich das richtig verstehen kann im Heimnetz nur mit dieser IP zugegriffen werden.

Aber wie sieht von ganz außen aus?
Ich habe die Domain über Proxy Manager an die IP geleitet.

Kann das in der /etc/vzdump.conf so bleiben?
Was meinst Du?

 

[Witker]

Wenn du den Share auf dem NAS dann so abgesichert hast, dass da nur noch ein User oder eine Gruppe mit Accountname + Passwort an den Share kommt, dann kannst du den Share direkt auf deinem Proxmox einbinden.

Mit User und PW ginge es mit CIFS ist das besser?

 

[Dunuin]

Berechtignung nur über IP ist eigentlich nicht so toll. Da braucht ja nur ein beliebiger infizierter Rechner mal alle 255 IPs durchgehen und gucken, mit welcher er Zugriff bekommt. Wenn man es wirklich darauf anlegt Schaden anzurichten, dann sind IP-Sperren kein wirkliches Hindernis. Aber immer noch besser als garnichts.
Wenn du keinen Authentifizierungsdienst wie z.B. Kerberos für NFS nutzen kannst, dann wäre SMB auch eine Option. Da ist die Authentifizierung mit Username und Passwort ja schon direkt im Protokoll verbaut. Das macht es dann schon deutlich sicherer. Besonders wenn du jedem Share eine eigene Gruppe gibst und jeder LXC/VM dann einen eigenen User hat der Mitglied der jeweiligen Gruppe ist, auf dessen Share du zugreifen willst.
So kannst du dann über die Nutzer/Gruppen einschränken, welcher LXC/VM da Lese- und/oder Schreibzugriff auf welche Shares haben darf.

 

[Witker]

Danke.
Unglaublich und das Sicherheitsloch kommt alles von dem einen Eintrag.
/etc/vzdump.conf
bei #tmpdir: DIR
tmpdir: /tmp

Nochmals vielen Dank das Du mich darauf hingewiesen hast.

SMB ist da nicht dabei


Mit User und PW ginge es mit CIFS ist das besser?


Aber, wenn Du mir bitte helfen würdest, würde ich gerne Deine Lösung von Oben verwenden.
Falls Deine Geduld mit mir es zulässt.

Ich muss das alles unbedingt lernen!

 

[Dunuin]

Das hier habe ich mir als Gedächtnishilfe aufgeschrieben. Vielleicht kannst du das ja als Anhaltspunkt nehmen:

14.) Falls Zugriff auf SMB Shares nötig ist:

CIFS-Utils installieren um SMB-Shares mounten zu können:
apt install cifs-utils

Datei mit SMB-Zugangsdaten erstellen:
nano /root/.smb_[FREIGABE_NAME]

Dort einfügen:
username=[USERNAME_VON_FREENAS]
password=[PASSWORT_VOM_FREENAS_USER]

chmod 0600 /root/.smb_[FREIGABE_NAME]

mkdir /media/[FREIGABE_NAME]
chown root:root /media/[FREIGABE_NAME]

nano /etc/fstab

Dort einfügen:
#SambaShares
//192.168.45.1/Podsync /media/Podsync cifs auto,rw,credentials=/root/.smb_[FREIGABE_NAME],uid=1100,gid=1100,file_mode=0660,dir_mode=0770 0 0

"credentials" entsprechend der vorher erstellten Datei anpassen sowie "uid" und "gid" auf den user setzen, der die Freigabe besitzen soll

Falls das in einem unprivilegierten LXC passieren soll muss der Share auf dem Proxmox-Host eingebunden werden und nicht in der VM.
Dazu sollte dann ein neuer User entsprechend des shares erstellt werden:
groupadd -g 1100 podsync
useradd -u 1100 -g podsync -s /usr/sbin/nologin podsync
passwd podsync
Dieser User sollte dann auch der uid und gid des Shares im fstab entsprechen.

Dann die Container UID Mappings des LXC anpassen:
nano /etc/pve/lxc/100.conf

Dort einfügen:
lxc.idmap = u 0 100000 1100
lxc.idmap = g 0 100000 1100
lxc.idmap = u 1100 1100 1
lxc.idmap = g 1100 1100 1
lxc.idmap = u 1101 101101 64435
lxc.idmap = g 1101 101101 64435
mp0: /media/PodSync,mp=/var/lib/docker/bm/podsync/data

Damit bleiben 1100 und gid 1100 im LXC gleich aber alle anderen uids/gids werden von 0 - 65535 nach 100000 - 165535 gemappt.
Der Pfad "/media/PodSync" auf dem Host wird nach "/var/lib/docker/bm/podsync/data" im LXC gebindet.

Dann auf dem Host das Mappen im LXC erlauben lassen:
nano /etc/subuid
Dort einfügen:
root:1100:1

nano /etc/subgid
Dort einfügen:
root:1100:1

Dann den selben User und Gruppe "podsync" im LXC erstellen:
groupadd -g 1100 podsync
useradd -u 1100 -g podsync -s /usr/sbin/nologin podsync
passwd podsync

Mehr siehe hier:
https://pve.proxmox.com/wiki/Unprivileged_LXC_containers

Da wollte ich einen user podsync (UID 1100) haben mit der gruppe podsync (GID 1100) der den SMB-Share "//192.168.45.1/Podsync" auf den Proxmox-Host nach "/media/Podsync" einbindet, welcher dann per Bind-Mount in den unprivilegierten LXC nach "/var/lib/docker/bm/podsync/data" durchgereicht wird.
Der SMB-Share wird mit "uid=1100,gid=1100,file_mode=0660,dir_mode=0770" eingebunden, also nur Lese-,Schreib- und Ausführbar für den User 1100 sowie alle User in die in der Gruppe 1100 sind.
Auf dem NAS müssen vorher entsprechend auch User/Gruppe podsync mit UID/GID 1100 angelegt und als Eigentümer des Shares bestimmt werden.

Ich meine aber mal gelesen zu haben, dass man da Shares besser nicht per fstab einbinden sollte, weil es beim Booten sonst zu Problemen kommen kann, wenn ein Share nicht erreichbar ist. Falls jemand weiß, wie man das besser macht, immer raus damit.

 

[Witker]

Bin jetzt bisschen verwirrt.
So wie ich es jetzt habe siehe, oben ist wäre es auch ohne den
Eintrag
/etc/vzdump.conf
bei #tmpdir: DIR
tmpdir: /tmp

schon unsicher?
Oder macht das erst der Eintrag?

 

[Dunuin]

Nein, generell denke ich. Du hast ja nicht geschrieben was du da genau gemacht hast und wie bei dir alles im Detail aussieht.

Mal was unsicher wäre:
-privilegierten LXC nutzt statt unprivilegierten
-NFS ohne Authentifizierung nutzen
-Shares nutzen wo jeder Nutzer Zugriff hat (chmod 777 usw)
-Shares nur per IP-Restriktion absichern
-alle LXCs/VMs mit den gleichen Zugangsdaten nutzen

Will man einen per Authentifizierung zugriffsbeschränken Share in einem unprivilegierten LXC nutzen, dann kommt man meines Wissens nicht um den Weg drum herum es so zu machen wie ich das oben beschrieben habe.

Deutlich leichter wäre es mit VMs. Da kann man sich das ganze Editieren usw. sparen und einfach direkt einen sicheren Share innerhalb der VM mounten.

Wenn du nur Proxmox einen vzdump auf das NAS schreibenlassen willst, dann brauchst du den ganzen Aufwand wohl nicht. Dann läuft ja alles auf dem Host ab und nicht im LXC selbst. Wichtig wäre das wie ich das oben gemacht habe, wenn du z.B. auch Daten von innerhalb des LXC direkt auf das NAS sichern möchtest. Oder du Daten erst garnicht auf der virtuellen Festplatte speichern möchtest, sondern der LXC die direkt vom NAS abrufen soll.

Rein für vzdump Backups reicht es, wenn du in Proxmox über die GUI ein SMB Share einbindest und diesen als Ziel für die Backups nimmst. Proxmox hat da ja root Rechte und darf alles.

Einfach nur der Eintrag "tmpdir: /tmp" sollte nicht das große Problem sein.