Martin Fellner

Proxmox Backupserver als LXC Container mit TrueNAS NFS Share?

9 min read

Backupserverei

Vor einem Monat habe ich zuletzt versucht meinen Backup-Server mit dem Proxmox Backup Server auszustatten. Das hat leider nicht so wirklich funktioniert, und jetzt, wo ich etwas mehr Zeit habe, versuche ich es noch einmal.

Achtung: Nach sehr langem hin und her, war die Lösung schließlich das Verwenden einer virtuellen Maschine anstelle eines LXC Containers. Ich habe bis zuletzt nicht ganz herausfinden können, woran es konkret gescheitert ist, aber nachdem es mit einer VM geht, werde ich mit dieser Lücke leben können. Der Vollständigkeit halber jedoch den ganzen Prozess hier nachzulesen, inklusive hin und her mit Chatbot. Vielleicht interessiert es ja jemanden.

Berechtigungen

Mit dem Chatbot mache ich meine Fehlersuchrecherche üblicherweise so, dass ich zuerst detailliert erkläre was ich gemacht habe und was das Ziel ist:

I installed proxmox on my backup server, there i installed truenas scale and passed through several hdds and made a dataset shared out via nfs. then i installed lxc pbs on the proxmox host and added the nfs share to the proxmox host and from there added it to the lxc pbs. Within the pbs lxc I can access the share and also create and delete files on the share /mnt/pbs-share. As far as I know in order to use the pbs lxc as a backup endpoint I need to add a datastore, but when I add the path /mnt/pbs-share as a datastore I get the error message "EPERM: Operation not permitted". I tried a few things already but I cant really get that working. What could cause this? How can I analyse it further (logs?)? and what could solve this?

Zuerst ein paar Logs holen:

journalctl -u proxmox-backup

und:

dmesg | grep denied

Die Ausgabe der Logs – durch etwaige sensible Angaben bereinigt – gebe ich dann wieder retour an das Sprachmodell:

ok, here is the journalctl - u proxmox-backup output: 
 
Dec 07 12:28:30 pbs proxmox-backup-api[147]: GET /api2/json/nodes/localhost/disks/zfs: 400 Bad Request: [client [::ffff:192.168.0.215]:44344] c> Try running 'udevadm trigger' and 'mount -t proc proc /proc' as root. Dec 07 12:28:30 pbs proxmox-backup-api[147]: error getting zfs devices: command "zpool" "list" "-H" "-p" "-P" "-v" failed - status code: 1 - /d> Dec 07 12:28:30 pbs proxmox-backup-api[147]: Try running 'udevadm trigger' and 'mount -t proc proc /proc' as root. Dec 07 12:28:37 pbs proxmox-backup-api[147]: error getting zfs devices: command "zpool" "list" "-H" "-p" "-P" "-v" failed - status code: 1 - /d> Dec 07 12:28:37 pbs proxmox-backup-api[147]: Try running 'udevadm trigger' and 'mount -t proc proc /proc' as root. Dec 07 12:33:37 pbs login[257607]: pam_unix(login:session): session opened for user root(uid=0) by root(uid=0) 
 
root@pbs:/mnt/pbs-share# dmesg | grep denied 
dmesg: read kernel buffer failed: Operation not permitted 
 
does this help?

Ich kann aus dem Stehgreif nicht einschätzen welche dieser Lösungen nun wirklich die richtige ist. Da ich ungern einfach alle einmal durchprobiere ist meine nächste Anfrage an GPT-40:

could you do a web search to verify which one of these issues/solutions might be it? I want some sources to that and not randomly try one solution after the other

Und schon wird es um einiges eindeutiger:

Ganz wichtig sind hier die unten genannten Quellen. Diese kann man zwar schön aufklappen lassen und dann anklicken…

… aber das ist ein wenig umständlich wenn ich sie kopieren möchte, daher mein nächster Prompt:

thanks, i see all the sources you just provided. That is great but could you spill them out for me here, to be able to copy them easily?

Nur da kommen leider nur zwei Quellen daher: Oder ausnahmsweise in Textform – normalerweise bevorzuge ich Screenshots von den Sprachmodellausgaben, da die Ausgabe genau wie meine Seite in Markdown geschieht und das die Formatierung zusammenhauen kann, und außerdem kann ich so eine krude Trennung zwischen dem von mir geschriebenen und dem eines Sprachmodells ziehen (Achtung, thought in progess) – um es leichter nachprüfen zu können:

Die Lösung ist wohl, dass a) der Ordner unter /mnt/pbs-share leer sein muss und b) er dem User backup mit der User und Group ID 34 zugewiesen esin muss (UID:GID 34:34). Ich habe aber, nachdem es sich um einen unprivilegierten Container handelt das Usermapping so gestaltet, dass ein User (und Gruppe) mit der ID 100000 auf der TrueNAS-Seite angelegt wurde… … und diese Nummer dann dem root User innerhalb des LXC Containers zugewiesen wird, via Mapping, siehe /etc/pve/lxc/<CT-ID>.conf:

{...}
unprivileged: 1
lxc.idmap: u 0 100000 999
lxc.idmap: g 0 100000 999
lxc.idmap: u 1000 101000 1
lxc.idmap: g 1000 101000 1
lxc.idmap: u 1001 101001 64535
lxc.idmap: g 1001 101001 64535

Das habe ich dem Chatbot geschildert, seine Antwort:

Das schaut zwar im ersten Moment gut aus, aber der User 100000 soll auf 34 gemappt werden und nicht 100034. Nach ein bisserl hin und her mit dem Chatbot bin ich dann auf dieses Mapping gekommen:

lxc.idmap: u 0 100001 33
lxc.idmap: g 0 100001 33
lxc.idmap: u 34 100000 1
lxc.idmap: g 34 100000 1
lxc.idmap: u 35 100035 64500
lxc.idmap: g 35 100035 64500

Leider startet das WebGUI von PBS dann gar nicht mehr. User ID-Mapping ist wirklich schwarze Magie, so sehr, dass es auch die leistungsstärksten Sprachmodelle dauernd aus der Spur wirft..

Also doch mit dieser Einstellung:

lxc.idmap: u 0 100000 34
lxc.idmap: g 0 100000 34
lxc.idmap: u 34 100034 1
lxc.idmap: g 34 100034 1
lxc.idmap: u 35 100035 64501
lxc.idmap: g 35 100035 64501
lxc.idmap: u 65534 165534 1
lxc.idmap: g 65534 165534 1

Nachtrag: die letzten beiden Zeilen sind notwendig, weil apt den user nobody braucht, oder so.

Nur habe ich jetzt den User und die Gruppe in TrueNAS Scale neu erstellen müssen, damit die ID 100034 vergeben werden kann und diese dann dem NFS-Share bzw. genauer dem Dataset zugewiesen werden kann. Aus Sicht des Containers gehört dieser Netzwerkshare dann dem User Backup. Ich habe vorher noch alle Ordner und Dateien im Share gelöscht, weil laut Proxomox-Thread oben, kann das auch Probleme machen.

EPERM: endloser Spaß mit Berechtigungen…

Dann habe ich mich frohen Mutes daran gemacht, endlich den Datastore hinzuzufügen, nur um wieder diesen nichtssagenden EPERM-Fehler zu sehen:

Also noch einmal zum Chatbot, dieser meint nun, nachdem ich ein paar Einstellungen in TrueNAS Scale durchgegangen bin:

Hier noch die beiden Beiträge im TrueNAS-Forum:

Dataset von POSIX auf NFSv4 umstellen

Also gut, dann ändern wir einmal von “POSIX” auf “NFS”. Dazu geht man auf das gewünschte Dataset und klickt bei “Dataset Details” auf “Edit”…

… dann auf “Advanced Options”:

Und dort “ACL type” von “Inherit” (was bei mir “POSIX” ist)…

… auf “SMB/NFSv4” und “ACL Mode” auf “Passthrough” ändern:

Achtung, Achtung:

Es sind eh keine Daten drauf, das sollte also kein Problem sein.

NFS-Share maproot squash

Dann unter “Sharing” den NFS-Share anklicken und ändern:

Dort auf “Advanced” und “Maproot User” auf “root” und “Maproot Group” auf “wheel” setzen:

Dann wieder beim Dataset auf “Permission” gehen und dort die ACLs anpassen und jetzt einmal als Preset “NFS4_OPEN” auswählen, da hier jeder schreiben und lesen kann:

Das habe ich nun auch noch rekursiv gespeichert. Aber das alleine hat jetzt auch nicht funktioniert.

Noch mehr herumprobieren, Pause, dann Lösung

Manchmal ist es hilfreich etwas anderes zu tun – wie zum Beispiel den Kaffeevollautomat zu zerlegen und zu putzen, oder vielleicht auch ein Spaziergang – und dann noch einmal frisch auf ein Problem zu schauen. Achja, und vielleicht noch einmal etwas recherchieren und damit ist nicht wild drauf los zu chatbotten sondern solide Anleitungen, wie diese, zu lesen.

Es war wohl nicht unbedingt alles notwendig, aber im Endeffekt hat es dann funktioniert:

aaaah: 

2024-12-08T01:51:35+01:00: TASK ERROR: Permission denied (os error 13)

sudo -u backup chmod -R 777 /mnt/pbs-share/pbs-datastore/.chunks

Noch einmal…

NFS neu einrichten, dann Backupserver neustarten und noch einmal probieren.

Alte NFS-Einstellung:

Dann löschen. Ebenso Dataset neu erstellen:

Wichtig hierbei “ACL Type” auf “SMB/NFSv4” und “ACL Mode” auf “Passthrough” setzen.

Dann Besitzer einstellen für Dataset, dazu habe ich wieder den pbs_user (UID/GID 100034) genommen:

Dann noch auf Set ACL klicken und zu Testzwecken “NFS4_OPEN” auswählen:

Und Einstellungen speichern:

Dann auf dem Proxmox Backup Server den alten NFS-Share löschen und den neuen hinzufügen:

Offen bleibt vorerst, ob ich gleich auf NFSv3 wechseln soll…

… zumindest wird in der Anleitung davon gesprochen, dass das man das bei Synology einstellen soll. Hm, vielleicht mache ich das gleich. Dazu geht man auf in TrueNAS auf “System Settings”, “Services”… … und auf die Einstellungen bei NFS, wo man sicherstellen kann, das V3 geht:

Ah gut, Version 3 ist eh eingeschaltet. Dann kann man unter PBS gleich unter “Advanced” die 3er Version auswählen:

Das ist auch der erste wirkliche Unterschied beim Aufsetzen im Vergleich zum ersten Versuch.

In der Shell vom Proxmox Host auf dem Backupserver, muss man dann als nächstes die Container Konfiguration (unter etc/pve/lxc/<CT-ID>.conf) anpassen, von…

mp0: /mnt/pve/pbs-share,mp=/mnt/pbs-share,acl=1

… auf:

mp0: /mnt/pve/pbs-wien,mp=/mnt/pbs-wien,acl=1

Neuer Versuch: Im PBS zuerst die Ordner erstellen und Berechtigungen setzen:

sudo -u backup mkdir /mnt/pbs-wien/pbs-datastore
sudo -u backup mkdir /mnt/pbs-wien/pbs-datastore/.chunks
sudo -u backup chmod -R 775 /mnt/pbs-wien/pbs-datastore/.chunks

Leider hat es wieder nicht funktioniert…

Lösung: VM

Es hat sich doch herausgestellt, dass ein LXC Container bei mir einfach nicht will. Ich habe jetzt stattdessen eine VM mit PBS erstellt und das hat funktioniert. Dazu habe ich die oben genannte Anleitung genau befolgt. Ein Unterschied war, dass ich jetzt explizit NFSv3 verwendet habe. Vielleicht hat das den Unterschied gemacht. Ich weiß es nicht, aber es sind schon genug Stunden in PBS geflossen, also bleibe ich bei der VM.

Ich habe das Gefühl, dass die Lösung fast funktioniert hat, aber halt nicht ganz und ich bin jetzt nicht mehr motiviert das noch einmal zu probieren.

Graphansicht

Backlinks