Mounter und NFS-Speicher

Der Mounter ist ein kleiner Container neben Restow, der den Docker-Socket hält. Seit 0.4.0 hat er zwei verschiedene Aufgaben, und es hilft, sie auseinanderzuhalten:

	NFS-Netzlaufwerke als Speicher	Freigaben als Quelle einer Sicherung
Was es ist	Eine NFS-Freigabe, die das Repository eines Mandanten oder das Standard-Repository der Installation aufnimmt, in `api` und `worker` unter `/mnt/restow/<Name>` eingehängt.	Eine SMB-Freigabe oder ein NFS-Export, den Restow vom Server aus sichert und in den es wiederherstellt.
Protokolle	Nur NFS. SMB ist seit 0.2.1 kein unterstützter Speicher-Mount mehr.	SMB und NFS (ab 0.4.0).
Wie es funktioniert	Der Mounter trägt die Freigabe in die Compose-Override-Datei ein und startet `api` und `worker` neu (ab 0.3.1).	Der Mounter startet für jeden Lauf einen kurzlebigen Runner-Container mit einem temporären Volume. Nichts wird neu gestartet (ab 0.4.0).
Wer	Der Provider-Inhaber fügt Freigaben hinzu, entfernt und testet sie, mit frischer Anmeldung.	Mandanten-Administratoren fügen ihre eigenen Freigaben hinzu, siehe Dateifreigaben.

Der größte Teil dieser Seite handelt von der ersten Aufgabe: Der Mounter bindet NFS-Freigaben über die Weboberfläche (Installation → Standard-Repository & Netzlaufwerke; seit 0.3.5 sind die früheren Seiten „Standard-Repository“ und „Netzlaufwerke“ wieder eine Seite, und alte Links zu den Netzlaufwerken öffnen sie) in eine Restow-Installation ein. So kann eine Freigabe das Speicherziel eines Mandanten oder den Speicher-Standard der Installation aufnehmen, ohne dass Sie Compose-Dateien von Hand bearbeiten. Die zweite Aufgabe hat weiter unten einen eigenen Abschnitt. Neue Installationen starten den Mounter seit 0.4.0 standardmäßig, siehe Aktivieren.

Was er für Speicher tut

Dieser Abschnitt handelt von NFS-Freigaben als Repository-Speicher. Der Mounter macht aus jeder Freigabe ein Docker-Volume des Treibers local mit NFS-Optionen und hängt es in api und worker unter /mnt/restow/<name> ein. Er trägt die Freigabe in die Compose-Override-Datei des Projekts ein (docker-compose.override.yml neben docker-compose.yml), sodass sie Neustarts, Updates (auch über den Updater) und ein docker compose up -d von Hand übersteht. Alles andere in der Override-Datei bleibt genau so, wie es ist, Kommentare eingeschlossen.

Danach legen Sie ein Speicherziel der Art „Verzeichnis“ mit dem Pfad /mnt/restow/<name> (oder einem Ordner darunter) an: Das Speicherformular bietet die Pfade der eingebundenen Freigaben an. Auch der Speicher-Standard der Installation kann dorthin zeigen.

Eine Änderung, Schritt für Schritt

Schritt	Was passiert
Einstellungen prüfen	Name, Server, Exportpfad und NFS-Version sind gültig; der Name ist frei; nichts in Ihrer eigenen Override-Datei ist schon unter `/mnt/restow/<name>` eingehängt.
Freigabe testen	Ein temporäres Volume (ein Soft-Mount, der schnell aufgibt) und ein kurzlebiger Container hängen die Freigabe ein, schreiben eine Datei, lesen sie zurück und entfernen sie.
Konfiguration schreiben	Die neue Override-Datei wird geschrieben, und `docker compose config -q` muss sie annehmen.
api und worker neu starten	`docker compose up -d --no-deps --no-build --pull never api worker`.
Warten, bis sie bereit sind	Die api meldet sich gesund, und der worker läuft (standardmäßig höchstens 5 Minuten).
Aufräumen	Volumes, die keine Freigabe mehr nutzt, werden entfernt.

Schlägt ein Schritt nach „Konfiguration schreiben“ fehl, stellt der Mounter die vorige Override-Datei wieder her und erstellt die Dienste erneut. Der Bereich zeigt dann „Fehlgeschlagen, der vorige Zustand wurde wiederhergestellt“. Die api verweigert eine Änderung, solange Backups, Restores oder andere Jobs laufen, und verweigert das Entfernen einer Freigabe, die ein Speicherziel eines Mandanten oder der Speicher-Standard noch nutzt. Das Entfernen einer Freigabe berührt nie die Daten auf dem NFS-Server.

Aktivieren

Der Mounter ist der Dienst mounter im Compose-Profil mounts der docker-compose.yml des Releases. Die Sicherung von Freigaben läuft über ihn, und ebenso das Hinzufügen einer NFS-Freigabe als Speicher.

Neue Installationen starten ihn standardmäßig (seit 0.4.0). install.sh startet das Profil mounts zusammen mit dem Stack. --no-mounter (oder der Alias --without-mounter) lässt ihn aus; --with-mounter wird weiter akzeptiert. Führen Sie das Installationsskript erneut auf einer bestehenden Installation aus, behält es deren Wahl und startet kein Profil.
Bestehende Installationen, mit dem optionalen Updater: Netzlaufwerke einschalten (seit 0.4.0). Solange der Mounter aus ist und der Updater läuft, sieht der Provider-Inhaber die Schaltfläche Netzlaufwerke einschalten (unter Installation → Standard-Repository & Netzlaufwerke, im Hinweis auf den Seiten der Freigaben und im NFS-Angebot des Speicherformulars). Sie braucht eine frische Anmeldung und steht im Audit-Log der Installation (mounter.enable_requested, dann mounter.enabled oder mounter.enable_failed). Die API leitet die Anfrage an den Updater weiter, der ablehnt, solange ein Update geplant ist oder läuft, prüft, dass docker-compose.yml den Dienst mounter im Profil mounts hat, und ihn in seinem Hilfscontainer startet. Das Ergebnis, gestartet oder fehlgeschlagen mit dem Grund, zeigt der Bereich. Das wurde vor dem Tag 0.4.0 nicht über einen echten Updater und seinen Docker-Hilfscontainer getestet.
Bestehende Installationen, ohne den Updater: ein Befehl. Im Verzeichnis mit docker-compose.yml:
Terminal-Fenster
```
docker compose --profile mounts up -d mounter
```

In der .env ist dafür keine Zeile nötig, und der Mounter braucht den Updater nicht (und der Updater nicht den Mounter). Eine Installation, die von 0.3.6 aktualisiert wurde, braucht für Freigaben außerdem die docker-compose.yml von 0.4.0 oder neuer, siehe Dateifreigaben: Voraussetzungen.

Image: das Anwendungs-Image, gestartet mit ROLE=mounter. Solange RESTOW_MOUNTER_IMAGE leer ist, startet der Dienst das Image aus RESTOW_IMAGE; beim ersten Start fixiert der Mounter RESTOW_MOUNTER_IMAGE in der .env per Digest, damit ein Update das Image mit dem Docker-Socket nicht ändert.
Netzwerk: Port 8091 nur im Compose-Netz, kein veröffentlichter Port. Die api erreicht ihn unter http://mounter:8091 (RESTOW_MOUNTER_URL).
Authentifizierung: ein zufälliges Secret, das der Mounter in das Volume restow-mounter-shared schreibt; die api hängt es nur lesend ein. Seit 0.4.0 hängt auch der Worker es nur lesend ein und hat RESTOW_MOUNTER_URL, weil der Worker die Läufe für Freigaben startet.
Wer ihn nutzen darf: Für NFS-Speicher sehen Provider-Administratoren mit allen Mandanten die Freigaben. Hinzufügen, Entfernen und Testen ist dem Inhaber vorbehalten und braucht eine frische Anmeldung. Jede Änderung und jeder Test landet im Audit-Log der Installation. Dateifreigaben fügen Mandanten-Administratoren über die API hinzu, siehe unten.

Zum Abschalten: docker compose --profile mounts stop mounter (nur ein Befehl: Die Weboberfläche schaltet ihn nicht ab). Die NFS-Speicher-Freigaben bleiben eingebunden; entfernen Sie sie zuerst in der Weboberfläche, wenn sie weg sollen. Laufende Läufe für Dateifreigaben enden dann als share.runner_lost, und solange er aus ist, startet kein neuer Lauf.

Runner für Freigaben (seit 0.4.0)

Für jeden Lauf einer Freigabe (eine Sicherung, eine Wiederherstellung oder eine Kopie) legt der Mounter ein temporäres Docker-Volume des Treibers local mit den Mount-Optionen der Freigabe an (Typ cifs oder nfs) und startet einen kurzlebigen Runner-Container mit diesem Volume unter /share, bei einer Sicherung schreibgeschützt. Endet der Lauf, entfernt er beide. Startet der Mounter, entfernt er Überreste anhand der Labels und übernimmt Läufe, die noch gehen. Eine laufende Sicherung hält ein Update des Mounters nicht auf, und beim Standard Sauber anhalten des Update-Dialogs wartet das Update auf Läufe von Freigaben, höchstens 30 Minuten, siehe Updates.

Das Image eines Runners ist das Image des laufenden Containers api, nie RESTOW_MOUNTER_IMAGE: Der Runner spricht mit dieser API, also muss er dieselbe Version sein. Findet der Mounter keinen Container api des Compose-Projekts, meldet er runner_image_unknown.
Das Netz runners ist ein internes Netz des Compose-Projekts, dem die api neben dem Standardnetz beitritt: keine Route nach außen. Ein Runner erreicht api:3000 und sonst nichts: nicht die Datenbank, nicht das Internet, nicht den Dateiserver (die Freigabe bindet der Kernel des Docker-Hosts ein, nicht der Container). Eine docker-compose.yml älter als 0.4.0 hat dieses Netz nicht, und der Mounter meldet dann runner_network_missing: Führen Sie das Installationsskript erneut aus, siehe Erneut ausführen.
Was ein Runner darf. Er läuft innen als root, mit allen Capabilities entzogen außer denen, die das Lesen braucht (DAC_READ_SEARCH, DAC_OVERRIDE; eine Wiederherstellung zusätzlich CHOWN, FOWNER und FSETID), no-new-privileges, einem schreibgeschützten Root-Dateisystem, höchstens 256 Prozessen und einem Speicherlimit. Er hält keine Datenbank-URL, keinen Master-Schlüssel und keinen Docker-Socket. Er hält ein Zugangsdatum, das nur für diesen einen Lauf gilt und nur Daten in sein eigenes Repository schreiben darf (ein Wiederherstellungslauf darf nur lesen), und das Passwort dieses Repositorys. Ein Test oder eine Ordnerliste läuft in einem Container ganz ohne Netz, mit 256 MiB, höchstens vier gleichzeitig.
Mount-Optionen. SMB-Mounts nutzen NTLMv2 innerhalb von NTLMSSP und die von Ihnen gewählte SMB-Version, nie SMB 1 und nie rohes NTLM, mit ausgeschalteten DFS-Verweisen. NFS-Mounts sind soft (timeo=600,retrans=3): Ein Server, der verschwindet, erzeugt nach etwa drei Minuten E/A-Fehler statt eines Prozesses, den nichts mehr beenden kann. Das ist absichtlich das Gegenteil des hard-Mounts von NFS-Speicher weiter unten.
Das Passwort einer SMB-Freigabe steht nur so lange in den Optionen des Volumes, wie der Lauf dauert, und sonst nirgends außerhalb des versiegelten Secrets. docker volume inspect zeigt die Optionen eines Volumes jedem, der den Docker-Socket erreicht, was auf dem Host ohnehin root ist; die kurze Lebensdauer des Volumes begrenzt es.
Grenzen. RESTOW_MOUNTER_MAX_RUNNERS (Standard 8) und RESTOW_MOUNTER_RUNNER_MAX_MEMORY_MIB (Standard 16384) begrenzen, was die Einstellungen unter Runner für Freigaben verlangen können, siehe Budgets, Netzwerke und Runner. Auf einem Host mit SELinux im Enforcing-Modus braucht der Mounter RESTOW_MOUNTER_SELINUX_CONTEXT=true in seiner Umgebung, siehe Überblick und Voraussetzungen.

Eine Dateifreigabe hinzuzufügen, zu testen, zu durchsuchen, zu sichern oder wiederherzustellen startet die api oder den worker nie neu. Das tun nur die NFS-Speicher-Freigaben oben.

Eine NFS-Adresse im Pfadfeld eines Repositorys (ab 0.3.3)

Seit 0.3.3 nimmt das Pfadfeld eines Verzeichnis-Repositorys auch eine NFS-Adresse an: 192.168.1.10:/export/backup, nas.local:/volume1/restow oder nfs://…. Der Provider-Inhaber kann sie dort testen und einbinden, und Restow trägt den Pfad ein. Laufen Jobs, wartet das Einbinden, bis keiner läuft, und lässt sich abbrechen; neue Jobs starten in der Zwischenzeit weiter, auf einem Server, der nie ruht, wartet das Einbinden also weiter. Das wurde gegen die Attrappen des Mounters getestet, noch nicht gegen einen echten NFS-Server. Ab 0.3.6 ist das Fenster Serverpfad hinzufügen breiter und scrollt nicht mehr zur Seite, damit die Adressen, Pfade und Befehle des NFS-Angebots hineinpassen.

Voraussetzungen für NFS

Diese Voraussetzungen gelten für NFS als Repository-Speicher. Ein NFS-Export als Dateifreigabe braucht denselben Client und dieselbe Adressregel und liest bei root_squash als nobody, siehe Dateifreigaben: Voraussetzungen.

NFS-Client im Host-Kernel. Der Treiber local von Docker hängt mit dem Kernel des Hosts ein. Auf einem minimalen Host installieren Sie nfs-common (Debian, Ubuntu) oder nfs-utils (RHEL-Familie), wenn ein Test mit „unknown filesystem type ‘nfs’“ scheitert.
Der Export muss diesen Host zulassen. Der Verkehr der Container verlässt den Host über dessen Adresse.
Root Squash. Restow schreibt in seinen Containern als root. Mit root_squash (Standard unter Linux, „Root dem Admin/Gast zuordnen“ bei Synology und QNAP) muss das exportierte Verzeichnis für den zugeordneten Benutzer beschreibbar sein (oft nobody, uid 65534), oder Sie nutzen all_squash mit anonuid/anongid eines Benutzers, dem das Verzeichnis gehört. Sonst meldet der Test „eingebunden, aber nicht beschreibbar“.
NFS-Version: 3, 4, 4.1 (Standard) und 4.2. NFSv4 braucht nur TCP 2049; NFSv3 zusätzlich rpcbind und mountd.
Mount-Optionen: Die Dienste hängen mit hard,noatime ein, sodass Schreibvorgänge auf einen verschwundenen Server warten, statt halb fertig abzubrechen.
Keine Zugangsdaten: Die Anmeldung erfolgt über den Host (AUTH_SYS); Kerberos wird nicht unterstützt.

Fehlersuche

Meldung	Ursache
Der Mounter läuft nicht	Mit dem angezeigten Befehl starten; `docker compose logs mounter` zeigt, warum er nicht startet. Ab 0.3.6 beginnt der Befehl im Installationsverzeichnis, siehe unten. Solange er aus ist, warten geplante Sicherungen von Dateifreigaben (`share.mounter_unavailable`).
Läufe für Dateifreigaben können nicht starten (`runner_network_missing`, `runner_image_unknown`)	Der Mounter läuft, kann aber keine Runner starten. Das erste heißt: Eine `docker-compose.yml` älter als 0.4.0 ohne das Netz `runners`: Führen Sie das Installationsskript erneut aus. Das zweite heißt: Er fand keinen Container `api`, dem er das Runner-Image entnehmen kann. Siehe Runner für Freigaben.
`no such service: mounter` (ab 0.3.6)	Die `docker-compose.yml` der Installation ist älter als der Mounter. Führen Sie das Installationsskript erneut aus, siehe unten.
Der Exportpfad … existiert auf … nicht. (ab 0.3.6)	Der Server hat geantwortet, exportiert aber keinen solchen Pfad. Siehe unten.
Das Netzlaufwerk konnte nicht eingebunden werden	Die Detailzeile enthält die Meldung von Docker: Zugriff verweigert (Export), Protokoll nicht unterstützt (NFS-Version), Zeitüberschreitung (Adresse oder Firewall), unbekannter Dateisystemtyp (kein NFS-Client auf dem Host). Bis 0.3.5 erschien ein falscher Exportpfad hier als „no such file“.
Das Netzlaufwerk wurde eingebunden, ist aber nicht beschreibbar	Siehe Root Squash oben.
Docker Compose hat die neue Konfiguration nicht angenommen	Ihre Override-Datei enthält etwas, das Compose zusammen mit der neuen Freigabe ablehnt; die vorige Datei wurde wiederhergestellt.
API oder Worker wurden nicht rechtzeitig bereit	Die vorige Override-Datei wurde wiederhergestellt; prüfen Sie `docker compose logs api worker`.
Fehlgeschlagen, bitte den Server prüfen	Auch das Zurückrollen schlug fehl. Vergleichen Sie `x-restow-mounts` in `docker-compose.override.yml` mit den Volumes `restow-nfs-*` und führen Sie dann `docker compose up -d` aus.

Der Mounter läuft nicht (ab 0.3.6)

Ab 0.3.6 beginnt der Befehl, den der Bereich zeigt, mit einem cd ins Installationsverzeichnis: cd <Verzeichnis> && docker compose --profile mounts up -d mounter. Das Verzeichnis ist RESTOW_PROJECT_DIR oder das, das der optionale Updater meldet. Kennt die api keines von beiden, zeigt der Bereich den Standard des Installationsskripts, /opt/restow, und sagt das; ist Restow in einem anderen Verzeichnis installiert, nehmen Sie dieses.

Hat die docker-compose.yml der Installation keinen Dienst mounter, sagt der Bereich das und zeigt den Befehl des Installationsskripts über dem Startbefehl. Er weiß das, wenn der Updater die Compose-Konfiguration liest oder wenn die api ohne das Volume des Mounters läuft.

`no such service: mounter` (ab 0.3.6)

Eine Installation behält die docker-compose.yml, mit der sie installiert wurde, und Updates, auch über den Updater, ändern nur die .env. Eine Datei aus der Zeit vor dem Mounter (eine Installation von vor 0.3.1; 0.3.0 wurde nie veröffentlicht) hat deshalb keinen Dienst mounter, und Compose antwortet no such service: mounter. Führen Sie ab 0.3.6 das Installationsskript des Releases, das Sie betreiben, erneut auf der Installation aus (--dir <Verzeichnis> nur, wenn es nicht /opt/restow ist):

curl -fsSLO https://github.com/restow-backup/restow/releases/download/v<Version>/install.sh && sudo bash install.sh

Es lädt die docker-compose.yml des in der .env genannten Releases, prüft sie gegen die signierte SHA256SUMS des Releases und behält, wenn sie abweicht, die alte Datei als docker-compose.yml.bak-<Zeit> und ersetzt sie. Die .env wird nicht geändert. Eigene Änderungen gehören in docker-compose.override.yml. Starten Sie dann den Mounter mit dem Befehl oben. Siehe Erneut ausführen.

Der Exportpfad existiert nicht (ab 0.3.6)

Der Server hat den Test beantwortet, exportiert aber keinen solchen Pfad (No such file or directory). Ab 0.3.6 nennt die Meldung den Pfad und den Server und sagt, wie Sie den richtigen finden:

Listen Sie mit showmount -e <Server> auf, was der Server exportiert, und übernehmen Sie den Pfad genau.
Auf einem Synology-NAS beginnt der Exportpfad mit dem Volume, zum Beispiel /volume1/<freigegebener Ordner>.
Mit NFSv4 zeigen manche Server ihre Exporte unterhalb eines Pseudo-Roots, unter anderen Pfaden als mit NFSv3. Probieren Sie NFS-Version 3.

Bekanntes Problem in 0.3.6: Der Docker-Fehlertext für einen fehlenden Export stammt aus der Dokumentation von Docker, nicht aus einer echten fehlgeschlagenen Einbindung. Erscheint die Meldung bei einem falschen Pfad nicht, sehen Sie stattdessen die allgemeine Zeile „Die Freigabe konnte nicht eingebunden werden“ oben, mit der eigenen Meldung von Docker in der Detailzeile.