„Sie mounten es falsch": Der NFS-Fehler, der Homelabs immer wieder zum Absturz bringt

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: anzunehmen, NFS funktioniere wie lokaler Speicher. Tut es nicht. Es geht nicht um das Vergrößern von Festplatten – es geht darum, Speicher korrekt freizugeben.

Die erste Weiche: VM vs. LXC (und warum das wichtiger ist, als Sie denken)

Fast sofort teilt sich das Gespräch in zwei Lager: Nutzen Sie eine VM oder ein LXC?

Denn 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."

Aber LXCs? Da wird es seltsam.

Jetzt haben Sie es mit Container-Grenzen, Mount-Points und Berechtigungs-Mapping zu tun. Es geht nicht mehr nur um „mit Speicher verbinden" – es geht um „wie führe ich Speicher sicher durch Abstraktionsschichten hindurch?"

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 nicht innerhalb des Containers mounten. Am Proxmox-Host mounten, dann 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

Es ist nicht spektakulär. Aber es funktioniert 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. Aber Ihre anderen Apps? 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/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 vs. unprivilegierte Container

Dann kommt die Diskussion, die sich nie wirklich klärt.

Manche sagen: Nutzen Sie einfach privilegierte Container. Das ist einfacher. Weniger Reibung. Alles funktioniert.

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 dagegen 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.

Jetzt wählen Sie also erneut: Bequemlichkeit oder Isolation.

Die Architektur-Frage: Ein Container vs. 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: ein Container pro App. Sauberer, sicherer, langfristig einfacher zu verwalten. 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 – aber sie zu kombinieren kann je nach Workflow sinnvoll sein.

Es gibt keine einzelne richtige Antwort. Nur Kompromisse.

Der Realitätscheck: NFS ist nicht der schwierige Teil

Hier 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 vs. VM vs. 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 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:

1. NFS auf dem Proxmox-Host mounten
2. In LXCs mit Mount-Points durchreichen
3. Berechtigungen richtig korrigieren

Es ist nicht der schnellste Weg. Aber es ist 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.