NFS lässt sich mit Proxmox Backup Server nicht nutzen

mscbs · September 17, 2025 at 2:15 PM

Ich versuche seit einiger Zeit, eine NFS-Freigabe auf meiner UGreen DXP2800 in einem Proxmox Backup Server als Datastore einzurichten. Leider gelingt mir das nicht.

Ich habe eine Freigabe "pbs-storage" eingerichtet. Auf diese habe ich den NFS-Zugriff erlaubt. Squash steht auf "Alle Benutzer als Admin zuordnen", Berechtigung ist "Lesen und Schreiben". Die IP des Backupservers ist ebenfalls zugelassen.

Ich kann die NFS-Freigabe im PBS mounten, bekomme aber keinen Zugriff auf den Ordner. Ich kann nicht mals als Root die Zugriffsrechte ändern. Der Ordner muss dem Owner backup zugewiesen werden. Der PBS kann dann natürlich auch keinen Datastore darauf einrichten. Als Fehlermeldung kommt: EPERM: Operation not permitted. Vermutlich, weil PBS den Owner nicht auf den User "backup" ändern kann.

Und warum kann man nur maximal NFS3 einrichten? NFS4 ist es schon so lange und das ist deutlich schneller. Warum es NFS4 noch nicht auf das UGOS geschafft hat, weiß wohl nur UGreen selber.

Hat es schon jemand geschafft, einen Datastore für PBS per NFS auf dem UGreen anzulegen? CIFS würde ich nur ungern nehmen, da NFS doch um einiges flotter ist. Und wenn ich das auf der Synology geschafft habe, sollte das auch auf der UGreen funktionieren.

EDIT: Man kann ganz normal Dateien und Ordner im NFS-Ordner speichern. Aber man den Owner nicht ändern, was aber für die Nutzung des PBS zwingend notwendig ist.

RBX · November 11, 2025 at 11:07 PM

Das exakt selbe Problem habe ich auch gerade mit meinem 4800 plus.

Es gibt wohl keine einfache Lösung, die man in der Oberfläche per Mausklick zusammen klickt.

Das Problem scheint zu sein dass das UGOS die Konfiguration des NFS Servers schützt. Selbst wenn man die /etc/Export per cli/ssh ändert, wird die Änderung verworfen, wenn der NFS Server neu gestartet wird. Die Änderung muss wohl im overlay Dateisystem geändert werden und dort fixiert werden, damit der NFS Server das beim Neustart übernimmt.

Ich werde testen und berichten.

chicokapi · November 13, 2025 at 10:07 AM

Ich verwende seit einigen Jahren "Qnap" mit "QuTS hero" (ZFS) als NFS Server für vSphere (früher), Proxmox (heute) und diverse Linux Clients. Aus Performance-, Stabilität- und Kostengründen erwäge ich derzeit einen Wechsel auf "Ugreen". Ebenfalls läuft ein "Proxmox Backup Server" als VM auf dem "Qnap", welcher neben des NFS-Dienstes, ebenfalls auf "Ugreen" übertragen werden muss!
Die von euch beschriebenen Probleme mit NFS sind so für mich natürlich ein Show-Stopper und ich bin deshalb an weiteren Infos in der Sache sehr interessiert! Besten Dank schon mal im Voraus!!!

alter Mann · November 13, 2025 at 12:42 PM

Quote from chicokapi

Die von euch beschriebenen Probleme mit NFS sind so für mich natürlich ein Show-Stopper

U.U. ist SAN und iSCSI eine Lösung.

bs00038bu · November 13, 2025 at 12:46 PM

Hallo zusammen,

mscbs, wenn ich deinen Beitrag richtig verstanden habe, dann ist es PBS nicht möglich auf die von dir angelegte Freigabe zuzugreifen, weil die eben nicht dem Benutzer "backup" gehört. Und du kannst den Eigentümer nicht ändern. Ist das so richtig?

Sollte das nicht zu umgehen sein, wenn du unterhalb dieser "verriegelten" Freigabe einen Unterordner anlegst (als root) und auf den mit 'chown' einen gewünschten/geforderten Benutzer als Eigentümer einträgst? In etwa chown backup:backup Unterordner/

Der Datastorage wäre dann über /Freigabename/Unterordner zu erreichen. Also, meiner bescheidenen Meinung nach.

mscbs · November 13, 2025 at 1:16 PM

Danke, das werde ich mal versuchen. Das wäre trotzdem nur ein "Workaround".

Ich habe jetzt folgendes gemacht und es funktioniert, soweit ich das testen konnte:

Verzeichnis /backup angelegt
auf dem NAS eine Freigabe pbs-storage angelegt
NFS Zugriff auf diese Freigabe für den PBS-server erlaubt
Squash: Root als Gast zuordnen (Alle Benutzer zu Admin zuordnen hat nicht funktioniert)
Freigabe gemountet: mount 192.168.2.2:/volume2/pbs-storage -t nfs /backup
ich konnte sogar den Owner von /backup setzen: chown -R backup:backup /backup
neuen Datastore unter /backup angelegt

Allerdings war nochmal ein Reboot nötig, da trotz korrekter Permissions kein Zugriff auf den Datastore möglich war und die Garbage Collection einen Zugriffsfehler angezeigt hat. Ich habe dann vor dem Reboot einen Eintrag in die fstab gemacht, damit die NFS-Freigabe automatisch gemountet wird, da ich den Backupserver immer noch nachts zum Backup starte und danach wieder runterfahre.

Es scheint also tatsächlich zu gehen. Ich habe aber vorher alles mögliche versucht. Scheinbar wurde mit irgendeinem Update doch was am NFS-Server geändert.

EDIT: Merkwürdigerweise standen die Permissions für den Ordner /backup komplett auf null. Also nochmal ein chmod -R 755 /backup und dann konnte ich auch auf den Datastore zugreifen.

ich lasse das ganze aber lieber noch parallel zum lokale auf dem PBS liegenden Datastore laufen und synchronisiere die Backups erstmal auf den NFS-Datastore.

6equj5 · November 13, 2025 at 2:35 PM

Quote from RBX

... Problem ... 4800 plus. ... wohl keine einfache Lösung ... UGOS ...

Ich hatte ja auch zeitweilig die DXP; aber nie UGOS. Auf der Büchse läuft einwandfrei PVE drauf. Und dann eben Kernel NFS und / oder Samba für simple, perfekt funktionierende NAS-Funktionen. Oder gleich der PBS, wenn das die Hauotfunktion sein soll, das dürfte auch gehen.

BlackHammer61 · December 21, 2025 at 1:58 PM

Quote from mscbs

Freigabe gemountet: mount 192.168.2.2:/volume2/pbs-storage -t nfs /backup

Hallo, ich bin komplett neu noch im NAS und Proxmox Game und hatte versucht, genau dieses Szenario nachzubilden.

Allerdings scheitert es bei mir immer noch am Mount.

Würde es dir etwas ausmachen, noch etwas genauer deinen Lösungsweg zu beschreiben? Auch was du genau in fstab eingetragen hast, würde ich gerne wissen..

Vielen Dank im Voraus!

mgoegel · January 1, 2026 at 12:19 PM

Moin,

das ist mein erster Post hier - und ein Gesundes Neues gleich mit! Ich hatte mir mein DXP6800 Pro im Dezember geholt, nach dem mein altes DS1520+ erst eine Disk ohne weiteres aus dem RAID geworfen hat (Vermutlich Verbindungsproblem an der Backplane) und am nächsten morgen die Disk mit den defekten Sektoren (die es mir nicht schon im Oktober gemeldet hatte) - was das RAID beinahe komplett vernichtet hat.
Ich konnte es extern richten und dann die Daten zum Glück auf das DXP migrieren.

Dort hatte ich auch das NFS Volume für meinen PBS. Ich war am hin und her überlegen, wie ich das am sinnvollsten Nutze.
NFS wollte ich nicht mehr nutzen, wegen der vielen Cluster Files.

ISCSI war meine Wahl, aber möglichst kein separates Volume. Ich fand heraus, dass es überhaupt kein Problem ist, eine große Image Datei auf dem Volume 1 mit der (vorläufigen) Zielgröße anzulegen.

Das Image kann ich natürlich nicht direkt über das GUI freigeben, das musste ich auf der Kommandozeile anlegen.

Zuerst das Volume Image erstellt:

Code

fallocate -l 1500G /volume1/iscsi/pxbackup.img

Anschließend das ISCSI Target anlegen:

Code

targetcli

/backstores/fileio create pbs_store /volume1/iscsi/pxbackup.img 1500G
/iscsi create iqn.2025-12.local.pbs:target
/iscsi/iqn.2025-12.local.pbs:target/tpg1/luns create /backstores/fileio/pbs_store
/iscsi/iqn.2025-12.local.pbs:target/tpg1/acls create iqn.1993-08.org.debian:xxxx
saveconfig

Der ACL Eintrag kommt vom PBS aus /etc/iscsi/initiatorname.scsi

Dann auf dem PBS:

Code

iscsiadm -m node --login --name iqn.2025-12.client
iscsiadm -m discovery -t sendtargets -p NAS-IP:3260

Nun sollte ein Blockdevice vorhanden sein lsblk
Bei mir war das dann /dev/sdc

Anschließend habe ich ein ZFS Pool erstellt:

Code

zpool list
zpool create pbs1 /dev/sdc

Und dann den PBS Datastore:

Code

proxmox-backup-manager datastore create dxp68a-backup /dev/pbs1

Im Nachgang gab es dann ein paar Probleme beim Reboot - der ZFS Pool wurde nicht sauber gefunden, weil das Volume (das Netzwerk) beim zfs-import-cache noch nicht verfügbar war.

Ich fand dafür ein separates systemd Script:

Code

[Unit]
Description=Wait for iSCSI LUN and restart zfs-import-cache.service
After=iscsid.service
After=network.target
[Service]
Type=oneshot
ExecStartPre=/usr/bin/sleep 10
ExecStart=/bin/bash -c 'iscsiadm --mode session; systemctl start zfs-import-cache.service; zpool import pbs1'
[Install]
WantedBy=zfs-import.target
WantedBy=multi-user.target

Display More

So richtig 100% scheint das nach einem Reboot (vom PBS) noch nicht zu laufen. Ich habe jetzt zwischen den Feiertagen auf PBS 4 aktualisiert, da kam es nach dem Reboot nicht im ersten Anlauf hoch. Beim zweiten Reboot war das Storage dann wieder verfügbar.

Das ist aber ein generelles ZFS/ISCSI Problem und hat nichts mit dem NAS zu tun.

Für mich ist die Lösung so akzeptabel. Generell will ich den PBS als VM wohl auf das NAS migrieren. Ich habe nur einen single Proxmox Home Server.

Die Entscheidung gegen NFS zeigte sich dann beim Update auf das aktuelle UGOS als bessere Wahl.

Ich habe einen alten MLD VDR Server und auf 2 Raspis VDR Clients, die die Aufzeichnungen per NFS mounten.
Die VDR uid am Server ist 666 - die hatte ich /etc/exports manuell konfiguriert. Der zerschießt mir das - ich kann das auch über das UI nicht anders konfigurieren. Das war bei Synology kein Problem. Ich muss da jetzt eine andere Lösung finden, weil die Clients mit der anonuid=1000 keinen Zugriff auf die Aufzeichnungen bekommen.

Gruß Mario

Edit:
oben fehlte noch das saveconfig.

mgoegel · January 8, 2026 at 3:04 PM

Ich weiß jetzt nicht genau, ob ich das saveconfig bei mir auch schon vergessen hatte, oder ob die config irgendwann vom NAS verworfen wurde (weil ich vor allem kein natives ISCSI Volume habe).

Ich halte euch auf dem laufenden, ob das auf Dauer wirklich so nutzbar ist...

Participate now!