Bei einer NAS-Freigabe im Docker-Host liegen die häufigsten Rechteprobleme nicht am Mount-Befehl allein, sondern an einer unklaren Zuordnung zwischen NAS-Benutzer, Host-Mount und Benutzer im Container. Bevor du einen Container neu erstellst oder Dateien verschiebst, solltest du deshalb zuerst feststellen, auf welcher Ebene der Zugriff scheitert: bei der Netzwerkfreigabe, im lokalen Mount, am Container-Pfad oder an der UID- und GID-Zuordnung. Solange die Datenlage nicht geprüft ist, solltest du weder Freigaben rekursiv auf „777“ setzen noch einen Container mit schreibendem Zugriff auf den gesamten Datenbestand starten.
Ein sicherer Aufbau besteht aus vier getrennten Ebenen: Die NAS stellt eine Freigabe bereit, der Docker-Host bindet diese Freigabe in sein Dateisystem ein, der Container erhält einen Mount auf einen internen Pfad und der Prozess im Container greift mit einer bestimmten Benutzer- und Gruppen-ID darauf zu. Jede Ebene kann funktionieren, während die nächste den Zugriff verweigert. Genau diese Trennung macht die Fehlersuche nachvollziehbar.
Welche Ebenen beim Mount zusammenspielen
Eine funktionierende Einbindung setzt voraus, dass alle beteiligten Pfade und Identitäten zueinander passen. Der Name einer NAS-Freigabe und der Pfad innerhalb des Containers sind dabei nicht automatisch identisch.
- NAS-Freigabe: Auf dem NAS regeln Freigabeberechtigungen und Dateisystemrechte, welcher Benutzer auf welche Daten zugreifen darf.
- Netzwerk-Mount auf dem Host: Der Docker-Host verbindet sich beispielsweise über SMB oder NFS mit der Freigabe und stellt sie als lokalen Pfad bereit.
- Bind-Mount: Docker reicht diesen lokalen Host-Pfad an einen Verzeichnispfad im Container weiter.
- Container-Prozess: Die Anwendung arbeitet mit einer UID, einer GID und eigenen Sicherheitsmechanismen. Diese Identität entscheidet über den Zugriff auf den eingebundenen Pfad.
Ein Ordner kann im Host-Terminal sichtbar sein, während die Anwendung im Container trotzdem „Permission denied“ meldet. Dann ist der Netzwerkzugriff wahrscheinlich in Ordnung; die Ursache liegt eher bei UID, GID, Gruppenrechten, einem schreibgeschützten Mount oder einer Anwendung, die einen anderen internen Pfad verwendet.
Vorbereitung: Daten, Freigabe und Zugriffsmodell prüfen
Bevor du einen Mount planst, solltest du festlegen, welche Daten die Anwendung benötigt und welche Aktionen sie ausführen darf. Eine Medienanwendung braucht oft nur Leserechte auf Bibliotheken, während eine Download- oder Synchronisationsanwendung zusätzlich in ein Arbeitsverzeichnis schreiben muss. Diese Bereiche sollten nicht ohne Grund als eine einzige Freigabe mit Vollzugriff eingebunden werden.
Prüfe auf dem NAS zunächst den vorgesehenen Freigabepfad, den verwendeten Protokolltyp und den NAS-Benutzer, mit dem der Host zugreift. Bei SMB werden Benutzername, Kennwort und gegebenenfalls die SMB-Version relevant. Bei NFS spielen Exportregeln, Hostberechtigungen und die Zuordnung von Benutzer- und Gruppen-IDs eine wichtige Rolle. Die Menünamen unterscheiden sich je nach NAS-System und Softwareversion; maßgeblich sind die Funktionen für Freigaben, Protokolle und Berechtigungen.
Der NAS-Benutzer für den Mount sollte kein unnötig privilegiertes Administratorkonto sein. Gib ihm nur die Freigaben und Schreibrechte, die für die vorgesehene Anwendung erforderlich sind. Speichere Zugangsdaten nicht ungeschützt in einer frei lesbaren Compose-Datei, wenn mehrere lokale Benutzer Zugriff auf den Docker-Host haben.
Den Host-Mount vom Container-Mount trennen
Der Host muss die NAS-Freigabe zuerst selbst erfolgreich erreichen. Erst danach sollte Docker den lokalen Mount-Punkt an den Container weiterreichen. Diese Reihenfolge verhindert, dass du einen Container als Testumgebung verwendest, obwohl die eigentliche Netzwerkverbindung noch nicht sauber funktioniert.
Ein sinnvoller Aufbau kann beispielsweise so aussehen:
- NAS-Freigabe: eine getrennte Datenfreigabe für die Anwendung
- Host-Mount: ein lokaler Pfad wie /srv/nas/media
- Container-Pfad: ein von der Anwendung erwarteter Pfad wie /media
Der Container muss nicht den Namen oder die Struktur der NAS-Freigabe kennen. Er sieht nur den internen Zielpfad. Dadurch kannst du die Host-Seite ändern, ohne die Anwendungskonfiguration vollständig umzubauen. Umgekehrt darfst du den Container-Pfad nicht beliebig wählen, wenn die Anwendung diesen Pfad in ihrer Bibliotheks- oder Konfigurationsdatei erwartet.
Ein typischer Bind-Mount besteht aus einer Quelle auf dem Host und einem Ziel im Container. Die Quelle muss auf dem Docker-Host existieren und auf die eingehängte NAS-Freigabe zeigen. Das Ziel muss im Container vorhanden sein oder von Docker angelegt werden können. Ein Tippfehler in der Host-Quelle kann dazu führen, dass Docker ein lokales leeres Verzeichnis verwendet. Die Anwendung startet dann scheinbar korrekt, sieht aber nicht die erwarteten NAS-Daten.
Warum UID und GID wichtiger sind als der Benutzername
Linux-Dateirechte speichern nicht den sichtbaren Benutzernamen, sondern numerische Benutzer- und Gruppen-IDs. Der Benutzer „media“ kann auf dem Host die UID 1001 besitzen, während derselbe Name im Container zur UID 1000 gehört. Stimmen die IDs nicht überein, erkennt das Dateisystem nicht automatisch, dass beide Konten denselben Zweck erfüllen.
Ermittle daher zuerst, unter welcher Identität die Anwendung im Container läuft. Je nach Image wird diese Einstellung über Umgebungsvariablen, ein Benutzerfeld, eine Startoption oder eine interne Standardkonfiguration festgelegt. Die Variablennamen sind nicht einheitlich und sollten aus der Dokumentation des verwendeten Images oder aus der bestehenden Containerkonfiguration übernommen werden.
Auf dem Host kannst du die Eigentümer und Rechte des Mount-Punkts prüfen. Entscheidend sind dabei nicht nur die Namen, sondern die numerischen Werte. Innerhalb des Containers muss anschließend dieselbe UID beziehungsweise eine passende Gruppenmitgliedschaft wirksam sein, sofern der NAS-Mount diese Zuordnung nicht bereits über seine Mount-Optionen abbildet.
Bei SMB wird der Zugriff auf die entfernte Freigabe häufig mit einem bestimmten NAS-Konto hergestellt. Die lokale Darstellung der Dateien und Verzeichnisse kann zusätzlich über Mount-Optionen beeinflusst werden. Bei NFS werden Dateibesitzer oft anhand numerischer IDs dargestellt. Das führt zu unterschiedlichen Fehlerbildern: Der Host kann lesen, aber nicht schreiben; der Container kann lesen, aber keine neuen Dateien anlegen; oder Unterverzeichnisse besitzen abweichende IDs.
Lesen und Schreiben bewusst getrennt planen
Ein Read-only-Mount ist für Bibliotheken, Archive und andere unveränderliche Daten oft die sicherere Wahl. Die Anwendung kann Dateien einlesen, aber weder löschen noch umbenennen oder durch fehlerhafte Automatisierung verändern. Schreibzugriff sollte nur dort aktiviert werden, wo der Dienst ihn tatsächlich benötigt.
Trenne bei Bedarf mindestens diese Bereiche:
- Bibliotheken oder Archivdaten mit möglichst nur lesendem Zugriff
- Arbeits- und Importverzeichnisse mit begrenztem Schreibzugriff
- Konfigurationsdaten des Containers
- temporäre Dateien und Cache-Daten
Ein Container, der seine Konfiguration in derselben Freigabe wie große Nutzdaten speichert, erschwert Backups und Wiederherstellungen. Konfigurationsdateien, Datenbanken und Zugangsdaten sollten einen eigenen Host-Pfad erhalten. Nutzdaten können separat eingebunden werden, gegebenenfalls mit unterschiedlichen Rechten.
Schreibzugriff begrenzen: Öffne nicht die gesamte NAS-Datenstruktur für einen Container, nur weil ein einzelner Unterordner beschreibbar sein muss. Ein eingeschränkter Pfad reduziert die Auswirkungen von Fehlkonfigurationen, kompromittierten Zugangsdaten und versehentlichen Löschvorgängen.
SMB oder NFS: Was bei der Planung zählt
SMB ist in gemischten Umgebungen mit Windows, macOS und Linux verbreitet und lässt sich auf vielen NAS-Systemen über einen Benutzerzugang nutzen. Für Docker-Anwendungen kann die Rechteabbildung trotzdem zusätzliche Aufmerksamkeit verlangen, insbesondere bei Dateien, die innerhalb des Containers erstellt werden.
NFS arbeitet stärker mit Unix-Rechten und numerischen IDs. Das kann bei Linux-basierten Docker-Hosts eine klare Zuordnung ermöglichen, setzt aber voraus, dass die Identitäten und Exportregeln sauber geplant sind. Eine Freigabe, die vom NAS nur für bestimmte Hosts exportiert wird, funktioniert nicht automatisch nach einem Wechsel der IP-Adresse oder des Netzwerks.
Die Entscheidung sollte nicht allein nach dem kürzesten Mount-Befehl fallen. Berücksichtige Protokollunterstützung des NAS, Netzwerksegmentierung, Ausfallszenarien, Dateisperren, benötigte Schreibvorgänge und die Anforderungen der Anwendung. Bei Datenbanken oder häufig veränderten Containerdaten ist ein Netzwerk-Mount nicht automatisch die beste Ablage. Latenz, Verbindungsabbrüche und Dateisystemverhalten können die Anwendung beeinträchtigen.
Mount-Punkte dauerhaft und nachvollziehbar einrichten
Ein manueller Mount kann für einen Test sinnvoll sein, reicht für einen dauerhaft betriebenen Container aber nicht aus. Nach einem Neustart muss der Docker-Host die Freigabe wieder einbinden, bevor der Container startet. Andernfalls kann Docker den lokalen Zielordner verwenden, obwohl die NAS-Freigabe noch nicht verfügbar ist.
Plane deshalb eine Startreihenfolge mit einer Abhängigkeit zwischen Netzwerk, NAS-Mount und Container. Der Host sollte den Mount-Zustand zuverlässig prüfen können. Ein bloß vorhandener Ordner ist kein Beweis dafür, dass die entfernte Freigabe eingehängt wurde.
Für Zugangsdaten und Mount-Optionen gelten die Sicherheitsregeln des Host-Betriebssystems. Eine Konfigurationsdatei mit Kennwörtern sollte nur für die erforderlichen Systemkonten lesbar sein. Vermeide Zugangsdaten in öffentlich zugänglichen Repositories, unverschlüsselten Backups oder Diagnoseausgaben.
Bei einem NAS-Ausfall muss außerdem klar sein, wie sich der Container verhalten soll. Manche Anwendungen warten auf den Pfad, andere starten mit einem leeren Verzeichnis oder erzeugen neue Daten lokal. Letzteres kann später zu einer Vermischung aus lokalen und entfernten Daten führen. Prüfe deshalb nach einem Neustart, ob der Mount wirklich aktiv ist, bevor der Dienst produktiv arbeitet.
Eine sichere Testreihenfolge für Rechteprobleme
Teste nicht alle Ebenen gleichzeitig. Die folgende Reihenfolge grenzt Fehler ein, ohne sofort Daten zu verändern.
- Prüfe auf dem NAS, ob der vorgesehene Benutzer die Freigabe lesen und – falls erforderlich – beschreiben darf.
- Prüfe auf dem Docker-Host, ob die Netzwerkfreigabe am vorgesehenen Mount-Punkt sichtbar ist.
- Lies eine vorhandene Testdatei vom Host aus und erstelle nur dann eine eindeutig benannte Testdatei, wenn Schreibzugriff benötigt wird.
- Prüfe Besitzer, Gruppen und numerische IDs am Host-Mount-Punkt.
- Starte den Container mit dem vorgesehenen Bind-Mount und teste den internen Zielpfad.
- Führe den Test mit derselben Benutzeridentität aus, die auch der Anwendungsprozess verwendet.
- Prüfe anschließend die Anwendung selbst: Bibliotheksscan, Import, Dateiänderung oder Löschvorgang müssen zur Berechtigung passen.
Wenn der Zugriff auf dem Host scheitert, ist der Container nicht der richtige Ansatzpunkt. Funktioniert der Hostzugriff, aber der Containerzugriff nicht, prüfst du als Nächstes den internen Pfad, die Container-UID, die GID und mögliche Sicherheitsprofile. Erkennt der Container die Dateien, kann die Anwendung aber nichts importieren, liegt die Ursache häufig in ihrer eigenen Konfiguration oder in einem abweichenden Pfad.
Typische Symptome richtig einordnen
Eine leere Medienbibliothek bedeutet nicht automatisch, dass die NAS-Freigabe leer ist. Häufig zeigt die Anwendung auf einen falschen Container-Pfad oder auf einen Host-Ordner, der beim Start vorübergehend nicht eingehängt war.
„Permission denied“ beim Lesen deutet meist auf fehlende Leserechte, eine falsche Identität oder einen eingeschränkten Export hin. Tritt der Fehler erst beim Anlegen oder Umbenennen auf, funktioniert der Lesezugriff möglicherweise bereits; dann fehlen Schreib- oder Änderungsrechte im Zielverzeichnis.
Wenn neue Dateien als unerwarteter Benutzer erscheinen, stimmt die UID- und GID-Planung nicht mit der gewünschten Eigentümerstruktur überein. Das Problem sollte nicht durch pauschales Ändern aller Rechte gelöst werden. Besser ist es, die Prozessidentität und die Mount-Konfiguration aufeinander abzustimmen.
Verschwinden Dateien nach einem Container-Neustart aus der Anwendung, solltest du kontrollieren, ob der Mount dauerhaft eingebunden wird und ob der Container tatsächlich denselben Host-Pfad verwendet. Ein Verzeichnis mit gleichem Namen kann auf Host und NAS zwei verschiedene Inhalte enthalten.
Docker-Konfiguration auf Wartbarkeit prüfen
Eine gute Containerdefinition macht Quelle, Ziel und Zugriffsrichtung eindeutig. Verwende verständliche Host-Pfade und dokumentiere, welche Anwendung welchen Container-Pfad nutzt. Relative Pfade erschweren die Fehlersuche, wenn der Container aus einem anderen Arbeitsverzeichnis gestartet wird.
Für jeden Mount sollte feststehen, ob er nur gelesen oder auch beschrieben werden darf. Konfigurationspfade, Medienpfade, Datenbanken und temporäre Verzeichnisse sollten nicht ohne Not zusammengelegt werden. Bei mehreren Containern muss außerdem geprüft werden, ob sie dieselbe UID- und GID-Strategie verwenden. Gleiche Namen allein schaffen keine gemeinsamen Dateirechte.
Vermeide privilegierte Container als schnelle Antwort auf Rechtefehler. Ein privilegierter Prozess kann mehr Ressourcen und Pfade erreichen, als für die Anwendung nötig ist. Das verschiebt die Ursache und vergrößert das Risiko. Erst wenn die Rechte, Mounts und Anwendungsvoraussetzungen geprüft sind, lässt sich beurteilen, ob eine spezielle Containerfunktion überhaupt erforderlich ist.
Backups und Rückweg vor Änderungen sichern
Ein Mount stellt Daten bereit, ersetzt aber kein Backup. RAID, Snapshots und Replikation können Ausfälle oder versehentliche Änderungen begrenzen, sind aber nicht mit einer unabhängig erreichbaren Sicherung gleichzusetzen. Bevor du Schreibrechte ausweitest oder eine Anwendung auf einen neuen Datenpfad umstellst, sollte eine überprüfbare Sicherung der wichtigen Daten vorhanden sein.
Plane Änderungen so, dass du den bisherigen Zustand wiederherstellen kannst. Halte den alten Mount-Pfad, die bisherige Containerdefinition und die relevanten Berechtigungen fest. Bei Konfigurationsänderungen solltest du den Container geordnet stoppen, die Datenpfade kontrollieren und erst danach die neue Zuordnung aktivieren.
Ein Wiederherstellungstest ist besonders wichtig, wenn die Anwendung Datenbanken, Metadaten oder Vorschaudateien erzeugt. Eine Sicherung, aus der sich nur einzelne Dateien kopieren lassen, stellt nicht zwangsläufig den vollständigen Dienst wieder her. Prüfe daher sowohl Nutzdaten als auch Konfiguration und die benötigten Zugangsdaten.
Prüfliste für einen sauberen Mount-Plan
Vor dem produktiven Einsatz sollten die folgenden Punkte beantwortet sein:
- Welche NAS-Freigabe wird verwendet und welches Protokoll bindet der Host ein?
- Welcher NAS-Benutzer darf lesen, schreiben oder löschen?
- Welcher Host-Pfad zeigt tatsächlich auf die eingehängte Freigabe?
- Welcher Container-Pfad wird von der Anwendung erwartet?
- Unter welcher UID und GID läuft der Prozess im Container?
- Welche Verzeichnisse müssen schreibbar sein und welche können read-only bleiben?
- Was passiert nach einem Neustart, bei einem Netzwerkausfall oder bei einer nicht verfügbaren Freigabe?
- Ist der Mount vor dem Containerstart aktiv?
- Gibt es ein getestetes Backup und einen Rückweg zur bisherigen Konfiguration?
Erst wenn diese Fragen beantwortet sind, lohnt sich die Feinabstimmung der Anwendung. So bleibt erkennbar, ob ein Fehler aus der NAS-Berechtigung, dem Host-Mount, dem Docker-Bind-Mount oder dem Anwendungsprozess stammt. Die wichtigste Sicherheitsregel bleibt dabei: Schreibrechte so klein wie möglich halten und jede Änderung zuerst mit einem kontrollierten Testpfad prüfen.
Häufige Fragen zu NAS-Docker-Mounts und Zugriffsrechten
Warum funktioniert ein NAS-Mount auf dem Docker-Host, aber nicht in der Anwendung?
Der Host-Test bestätigt nur, dass die Netzwerkfreigabe erreichbar ist. Im Container kann trotzdem eine andere UID, GID, Mount-Option oder ein abweichender interner Pfad wirksam sein, sodass die Anwendung den Zugriff verweigert.
Ist SMB oder NFS für einen Docker-Mount auf dem NAS besser geeignet?
Eine pauschale Empfehlung gibt es nicht, weil NAS-Modell, Docker-Host und gewünschtes Zugriffsmodell entscheidend sind. SMB arbeitet häufig über ein NAS-Konto, während NFS stärker auf Hostfreigaben und numerische Benutzer- und Gruppen-IDs angewiesen ist.
Was bedeutet ein leerer Ordner im Container trotz vorhandener NAS-Daten?
Oft zeigt der Bind-Mount auf einen falschen oder nicht aktiven Host-Pfad. Prüfe deshalb vor dem Containerstart, ob der Host-Pfad tatsächlich die NAS-Freigabe enthält und ob Docker nicht versehentlich ein lokales leeres Verzeichnis verwendet.
Wie verhindere ich, dass ein Container nach einem NAS-Ausfall lokale Daten anlegt?
Ein nicht verfügbarer Netzwerk-Mount kann je nach Aufbau dazu führen, dass der Host-Pfad lokal weiterexistiert und der Container dort schreibt. Begrenze den Schreibzugriff, stelle die Verfügbarkeit des Mounts vor dem Containerstart sicher und kontrolliere nach Netzwerkausfällen den tatsächlich verwendeten Pfad.
Kann ich die Rechte auf der NAS-Freigabe einfach auf 777 setzen?
Das ist keine saubere Lösung, weil dadurch unnötig viele lokale oder entfernte Prozesse schreiben und löschen könnten. Ermittle stattdessen die benötigte UID- und GID-Zuordnung und erteile nur den Verzeichnissen Schreibrechte, die der Dienst tatsächlich verändern muss.
Was muss ich bei mehreren Docker-Containern mit derselben NAS-Freigabe beachten?
Gleiche Dateipfade oder gleiche Benutzernamen sorgen nicht automatisch für gemeinsame Zugriffsrechte. Prüfe für jeden Container die numerischen IDs, den benötigten Schreibumfang und mögliche Konflikte bei Datenbanken, temporären Dateien oder automatisch erzeugten Metadaten.
Welche Rechte braucht ein Container für einen sicheren Read-only-Mount?
Für das reine Lesen muss der Prozess die Verzeichnisse betreten und Dateien lesen dürfen, aber nicht schreiben, löschen oder umbenennen können. Zusätzlich muss der Docker-Mount selbst als schreibgeschützt eingebunden sein, sofern die Anwendung keine Änderungen an diesen Daten benötigt.
Was sollte ich vor einer Rechteänderung an einem produktiven NAS-Docker-Mount sichern?
Halte die bisherige Containerdefinition, Mount-Pfade, NAS-Zugangsdaten und relevanten Berechtigungen fest, damit du die Änderung zurücknehmen kannst. Für wichtige Nutzdaten und die Anwendungskonfiguration sollte außerdem ein getestetes Backup existieren, bevor Schreibrechte erweitert oder Pfade umgestellt werden.