Der Benutzer hatte Syncthing für die Synchronisierung von Handyfotos zum Laufen gebracht, aber die Dateien landeten weiterhin auf dem Systemlaufwerk statt auf dem Speicherlaufwerk. Das Kopieren eines Pfads aus der Dateien-App und direkte Einfügen dieses Pfads in Syncthing führte dazu, dass Syncthing dieselbe Verzeichnisstruktur innerhalb des eigenen Containerdateisystems neu erstellte.
Die letztendliche Lösung war konzeptioneller Natur und kein magischer Dateisystembefehl: Docker hat einen Hostpfad und einen Containerpfad. Syncthing muss den innerhalb des Containers sichtbaren Pfad verwenden, nicht den rohen Pfad, den CasaOS oder ZimaOS anzeigt.
Warum der externe Pfad am falschen Ort neu erstellt wurde
Wenn Syncthing angewiesen wird, einen Pfad zu verwenden, den es tatsächlich nicht sehen kann, erstellt es diesen möglicherweise in seinem eigenen beschreibbaren Dateisystem oder innerhalb eines zugeordneten Konfigurationsverzeichnisses. Der Benutzer interpretierte den Ordnernamen als Pfad zu einer externen Festplatte, während der Container ihn als Pfad relativ zu seinem eigenen Dateisystem interpretierte.
Tatsächlichen Host-Einhängepunkt ermitteln
Die Community verwendete lsblk angezeigt, um festzustellen, wo das Betriebssystem das externe Laufwerk eingehängt hatte. Im Beispiel des Antwortenden erschien das Laufwerk unter einem Pfad ähnlich wie /media/devmon/...; die Laufwerke des ursprünglichen Verfassers wurden später unter /mnt/Storage1 und /mnt/Storage2.
Diese historischen Einhängepfade sind Beispiele für CasaOS/ZimaBlade und sollten nicht als aktuell allgemeingültige ZimaOS-Pfade betrachtet werden.
Host-Laufwerk in Syncthing einbinden
Der Antwortende verwendete /DATA als Pfad auf der Syncthing-Seite. Sobald diese Zuordnung besteht, sollte Syncthing auf Unterordner von /DATA statt des ursprünglichen Host-Einhängepfads.
Der Benutzer gab zunächst den Hostpfad in Syncthing ein
Syncthing meldete daraufhin einen Berechtigungs- bzw. Pfadfehler, weil dieser interne Pfad nicht dem zugeordneten Volume entsprach.
Der endgültig funktionierende Pfad war /DATA/Documents
Der Antwortende erklärte, dass Syncthing nach der Zuordnung des Host-Laufwerks zu /DATAsollte Syncthing Folgendes verwenden:
/DATA/Documentsoder das entsprechende Verzeichnis ~/Documents verkürzter Pfad verwendet, wenn Syncthings Home-Verzeichnis auf diesen zugeordneten Datenpfad zeigt.
Der ursprüngliche Verfasser meldete sich am nächsten Tag zurück und bestätigte den Erfolg.
Rekursives chown war Teil des Community-Workflows, nicht der eigentlichen Lösung
Im Thread wurde außerdem ein rekursiver chown auf dem externen Laufwerk. Das kann bei einem von Linux verwalteten Dateisystem angemessen sein, ändert jedoch die Eigentumsrechte im gesamten Ziel und war keine von IceWhale verfasste Anforderung.
Ändern Sie den Eigentümer eines bestehenden gemeinsam genutzten Laufwerks nicht rekursiv, bevor Sie wissen, welche Benutzer und Anwendungen bereits auf dessen Berechtigungen angewiesen sind.
Das aktuelle ZimaOS erleichtert die Zuordnung des Anwendungsspeichers
Das aktuelle ZimaOS dokumentiert Host- und Container-Pfade direkt in den Anwendungseinstellungen und empfiehlt, Anwendungsdaten im verwalteten Speicher abzulegen, anstatt Anwendungen die Systemfestplatte füllen zu lassen.
Verwenden Sie das aktuelle ZimaOS-Modell für Anwendungspfade bei Docker-Volumes, anstatt sich auf alte CasaOS-Einhängeorte zu verlassen.
Der ursprüngliche Nutzer installierte Syncthing neu und erstellte die Zuordnung erneut
Nachdem die ersten Versuche weiterhin unklar blieben, führte der ursprüngliche Verfasser eine neue Syncthing-Installation durch, fügte die Speicherlaufwerke erneut hinzu und ordnete /mnt/Storage1 auf dem Host nach /DATA im Container. Durch diesen sauberen erneuten Test wurden alte Container-Einstellungen aus der Diagnose entfernt.
Alleinige Host-Berechtigungen konnten den falschen Container-Pfad nicht funktionsfähig machen
Der Benutzer konnte sich per SSH mit dem Speicherlaufwerk verbinden und Verzeichnisse erstellen, doch Syncthing schlug weiterhin fehl, als es den Pfad /mnt/Storage1/Documents im Container. Dieses negative Ergebnis ist wertvoll: Dass der Host-Benutzer schreiben kann, bedeutet nicht, dass der Container denselben Namensraum sehen kann.
Die Sichtbarkeit im Container muss korrekt sein, bevor eine Anpassung der Berechtigungen überhaupt etwas bewirken kann.
Das aktuelle ZimaOS sollte bevorzugt verwaltete Speicherpfade verwenden
Der Beitrag stammt von einem ZimaBlade, das mit CasaOS-ähnlichen Speicherpfaden ausgeliefert wurde. Das aktuelle ZimaOS verwendet ein anderes Verhalten bei der Speicherverwaltung und bietet eine übersichtlichere Oberfläche für Anwendungs-Volumes. Verwenden Sie auf einem aktuellen Server den über ZimaOS ausgewählten Speicherpfad, anstatt einfach anzunehmen, /mnt/Storage1 oder /media/devmon wird vorhanden sein.
Nur die tatsächlich benötigten Berechtigungen der App ändern
Syncthing benötigt normalerweise Lese- und Schreibzugriff auf seinen Synchronisierungsordner. Wenn ein eingebundener Ordner sichtbar, aber nicht beschreibbar ist, überprüfen Sie die Eigentums- und Gruppenberechtigungen genau dieses Ordners. Vermeiden Sie es, den Eigentümer rekursiv auf einem gesamten Laufwerk mit mehreren Verwendungszwecken zu ändern, es sei denn, Sie haben alle anderen Dienste berücksichtigt, die dieses Laufwerk verwenden.
Syncthing-FAQ zur externen Festplatte
Warum hat Syncthing den Pfad des externen Laufwerks auf der Systemfestplatte erstellt?
Der Host-Pfad war nicht der Pfad, den Syncthing innerhalb seines Containers sehen konnte.
Welcher Pfad funktionierte, nachdem das Laufwerk nach /DATA eingebunden worden war?
Der ursprüngliche Nutzer bestätigte /DATA/Documents funktionierte.
War ein rekursives chown die einzige Lösung?
Nein. Die entscheidende Erkenntnis war der Unterschied zwischen Host-Pfad und Container-Pfad.
