Der NFS-Fehler, an dem Homelabs mit Proxmox immer wieder scheitern
Die Verwirrung: „Warum sieht meine VM meinen Speicher nicht einfach?"
Es beginnt einfach genug. Sie haben eine Proxmox-VM mit begrenztem Speicher, vielleicht 100 GB, und ein völlig funktionsfähiges NAS mit Terabytes an freiem Platz. Das Ziel wirkt offensichtlich: die beiden verbinden und weitermachen.
Doch dann stoßen Sie auf die Mauer. Wo ist der Pfad? Müssen Sie mehr Speicher partitionieren? Festplatten jedes Mal neu dimensionieren? Plötzlich wird aus etwas, das sich wie Plug-and-Play anfühlen sollte, ein Labyrinth aus Mounten, Berechtigungen und widersprüchlichen Ratschlägen.
Und das ist der erste Fehler, nämlich anzunehmen, NFS funktioniere wie lokaler Speicher. Tut es nicht. Hier geht es darum, Speicher korrekt freizugeben, und nicht darum, Festplatten zu vergrößern.
Die erste Weiche: VM oder LXC
Fast sofort teilt sich das Gespräch in zwei Lager: Nutzen Sie eine VM oder ein LXC? Die Antwort ändert alles.
Bei VMs ist der Rat erfrischend unspektakulär. Mounten Sie die NFS-Freigabe einfach innerhalb der VM über /etc/fstab, und fertig. Ein Kommentator brachte es einfach auf den Punkt: „Bei einer VM macht man das einfach über fstab … dann mount -a."
Bei LXCs wird es dagegen seltsam. Jetzt haben Sie es mit Container-Grenzen, Mount-Points und Berechtigungs-Mapping zu tun. Die Frage lautet jetzt, wie Sie Speicher sicher durch Abstraktionsschichten hindurchführen, und nicht mehr, wie Sie sich überhaupt verbinden. Und genau dort beginnen die meisten Setups zu zerbrechen.
Der saubere Ansatz: am Host mounten, dann durchreichen
Eine der konsistentesten Empfehlungen schneidet durch den Lärm: NFS am Proxmox-Host mounten, nicht im Container, und von dort in das LXC durchreichen. Das klingt nach zusätzlicher Arbeit, vereinfacht aber alles.
Ein Nutzer legte es Schritt für Schritt dar: die NAS-Freigabe an etwas wie /mnt/proxmox_nfs auf dem Host mounten, dann einen Mount-Point in der LXC-Konfiguration hinzufügen, damit der Container darauf zugreifen kann.
Dieser Ansatz bewirkt zwei Dinge:
- Hält Netzwerk- und Speicherlogik zentralisiert
- Vermeidet merkwürdige Container-Berechtigungsprobleme
Spektakulär ist das nicht, es funktioniert aber konsistent. Und in Homelabs schlägt Konsistenz meist Cleverness.
Der Berechtigungs-Albtraum: „Warum kann Plex es sehen, aber sonst nichts?"
Hier bricht wirklich alles zusammen. Sie mounten die Freigabe, sie erscheint, Plex kann sie lesen. Ihre anderen Apps bekommen dagegen nichts: kein Zugriff, keine Fehler, nur Stille.
Das liegt an den Benutzerberechtigungen innerhalb der Container. Ein frustrierter Kommentar brachte es perfekt auf den Punkt: Ein LXC kann auf das NAS zugreifen, aber andere „nutzen einen Root-Benutzer, der nicht darauf zugreifen kann", selbst mit Bind-Mounts.
Das ist der Teil, den einem niemand vorher sagt. Mounten ist einfach, Berechtigungen sind das eigentliche Problem. Sie haben es mit UID- und GID-Diskrepanzen zwischen folgenden Parteien zu tun:
- Dem NAS
- Dem Proxmox-Host
- Den Container-Benutzern
Wenn diese nicht übereinstimmen, bricht der Zugriff, selbst wenn alles korrekt aussieht.
Die Sicherheitsdebatte: privilegierte oder unprivilegierte Container
Dann kommt die Diskussion, die sich nie wirklich klärt. Manche sagen, nutzen Sie einfach privilegierte Container, das sei einfacher, weniger reibungsanfällig, und alles funktioniere. Andere widersprechen vehement: „Privilegierte LXCs sind eine schreckliche Idee."
Und sie liegen nicht falsch. Privilegierte Container verwischen die Isolationsgrenze. Sie machen das Mounten einfacher, aber auf Kosten der Sicherheit. Unprivilegierte Container sind sicherer, erfordern aber mehr Aufwand, besonders bei den Berechtigungen.
Ein Nutzer verteidigt unprivilegierte LXCs vehement und argumentiert, sie seien „sicher af", wenn korrekt konfiguriert, und würden die Kopfschmerzen von VMs bei Dingen wie GPU-Sharing vermeiden. Sie wählen also erneut zwischen Bequemlichkeit und Isolation.
Die Architektur-Frage: ein Container oder viele
Gerade wenn Sie denken, Sie hätten es herausgefunden, taucht eine weitere Debatte auf. Lassen Sie alles in einem Container laufen, oder verteilen Sie Dienste auf mehrere LXCs?
Manche plädieren für Trennung, also einen Container pro App, weil das sauberer und sicherer ist und sich langfristig einfacher verwalten lässt. Andere bevorzugen es, Dienste zu bündeln, um Netzwerk- und VPN-Setups zu vereinfachen. Eine Meinung fasst es gut zusammen: Separate Container sind insgesamt einfacher, sie zu kombinieren kann je nach Workflow aber sinnvoll sein. Eine einzelne richtige Antwort gibt es nicht, nur Kompromisse.
Der Realitätscheck: NFS ist nicht der schwierige Teil
Hier kommt die Wendung. NFS selbst ist eigentlich einfach: eine Freigabe definieren, mounten, fertig. Wie ein Kommentator anmerkte, ist es im Grunde nur:
IP:/path/to/share → /mnt/path
Die Komplexität entsteht aus allem drumherum:
- Wo Sie mounten (Host, VM oder LXC)
- Wie Sie freigeben (Bind-Mounts, Konfigurationsdateien)
- Wer Zugriff hat (Berechtigungen, User-Mapping)
Deshalb fühlt es sich schwieriger an, als es sein sollte. Sie mounten hier nicht nur Speicher, Sie integrieren Systeme.
Das Fazit: Hören Sie auf, die falsche Ebene zu bekämpfen
Wenn es hier eine Lektion gibt, dann diese: Die meisten Menschen kämpfen mit NFS, weil sie das falsche Problem lösen. Sie versuchen:
- VM-Festplatten zu vergrößern, statt Netzwerkspeicher zu nutzen
- Direkt innerhalb von Containern zu mounten, statt den Host zu nutzen
- Berechtigungen zu ignorieren, bis alles zusammenbricht
Der reibungslosere Weg sieht fast immer so aus:
- NFS auf dem Proxmox-Host mounten
- In LXCs mit Mount-Points durchreichen
- Berechtigungen richtig korrigieren
Der schnellste Weg ist das nicht, aber der, der einen später nicht wieder einholt. Und in einem Homelab ist das der Unterschied zwischen etwas, das heute funktioniert, und etwas, das auch nächsten Monat noch funktioniert.