CasaOS-Syncthing-Ordner funktioniert auf einem anderen Laufwerk nicht

Wichtige Schlussfolgerung: Dies ist wahrscheinlich kein Problem nach dem Muster „Ändere immer wieder chmod, bis Syncthing funktioniert“. Das stärkere Indiz ist, dass der Ordner funktioniert, wenn er sich in einem Pfad befindet, den Syncthing direkt sehen kann, aber fehlschlägt, wenn ein symbolischer Link auf ein anderes physisches Laufwerk führt. In CasaOS deutet das zunächst auf die in den Container eingebundenen Pfade und anschließend auf die UID-/GID-Berechtigungen hin.

„Ich habe bereits überall die Berechtigungen gesetzt … es funktioniert, wenn ich /DATA/AppData/ als Ziel angebe, aber nicht, wenn der Link auf ein anderes physisches Laufwerk zeigt.“ Dieses Testergebnis ist aussagekräftiger als der ursprüngliche Berechtigungsfehler, weil es das Problem auf den Speicherpfad eingrenzt.

Warum der symbolische Link als Erstes hinterfragt werden sollte

Syncthing behandelt einen symbolischen Link nicht nach dem Muster „Bitte springe zum Ziel und synchronisiere alles, was sich dort befindet“. Das dokumentierte Verhalten symbolischer Links in Syncthing besteht darin, dass symbolische Links zwar synchronisiert, aber niemals verfolgt werden. Auch die Ordnerkonfiguration erwartet einen realen, gerätebezogenen Pfad: Der Syncthing-Ordnerpfad ist der physische Pfad zum Ordner auf der Festplatte.

Das macht einen Pfad wie diesen verdächtig:

/DATA/Documents/Syncthing/SyncFiles → symbolischer Link → /some/other/physical/drive

Wenn Syncthing in Docker ausgeführt wird, kann der Host diesen Link auflösen, während der Container das Ziel möglicherweise überhaupt nicht sehen kann.

Die CasaOS-Syncthing-App erklärt, warum ein zweites Laufwerk verschwinden kann

Die offizielle CasaOS-App-Store-Definition für Syncthing ist hier ungewöhnlich hilfreich. Ihre Compose-Datei bindet zwei Host-Pfade in den Container ein:

/DATA/AppData/$AppID/config → /config
/DATA                      → /DATA

Die tatsächliche Volume-Zuordnung können Sie in der CasaOS-Syncthing-Compose-Datei überprüfen.

Das bedeutet: Ein Ziel, das auf dem Host physisch innerhalb des /DATA-Baums liegt, sollte auch unter /DATA im Syncthing-Container sichtbar sein. Wenn der symbolische Link letztlich jedoch auf einen Host-Mount außerhalb dieses Baums zeigt, benötigt der Container einen separaten Bind-Mount für das tatsächliche Ziel. Mit Docker-Bind-Mounts müssen Host-Verzeichnisse explizit in den Container eingebunden werden.

Use this test to distinguish a path problem from a permission problem

Verwende diesen Test, um ein Pfadproblem von einem Berechtigungsproblem zu unterscheiden.

Führe die Prüfungen in dieser Reihenfolge durch. Beginne nicht mit einem weiteren rekursiven chmod.

1. Löse den tatsächlichen Pfad auf dem CasaOS-Host auf.

readlink -f "/DATA/Documents/Syncthing/SyncFiles" /DATAWenn der Befehl einen Pfad außerhalb von

2. Frage den Syncthing-Container, ob er dasselbe Ziel sehen kann.

docker exec syncthing ls -ld "/DATA/Documents/Syncthing/SyncFiles"

Teste anschließend das aufgelöste Ziel, falls es innerhalb des Containers vorhanden sein sollte. Wenn der Host es auflisten kann, der Container jedoch nicht, sind Berechtigungen noch nicht das Hauptproblem; der Pfad fehlt im Namespace des Containers.

3. Untersuche die tatsächlichen Container-Mounts.

docker inspect syncthing

Sieh dir den Mounts Abschnitt. Du solltest die Quelle auf dem Host und das Containerziel für das Laufwerk identifizieren können, das du synchronisieren möchtest.

Die sauberere Lösung: Binde das tatsächliche Laufwerk ein und verwende anschließend diesen Containerpfad.

Wenn sich das externe Laufwerk außerhalb von /DATAund binde es direkt in Syncthing ein, statt es hinter einem symbolischen Link zu verbergen. Der Compose-Eintrag sieht konzeptionell so aus:

volumes:
  - type: bind
    source: /real/host/path/to/external-drive
    target: /sync-drive

Konfiguriere den Syncthing-Ordnerpfad dann explizit, zum Beispiel:

/sync-drive/Dev Files

Dies ist kein magischer Pfad. Wähle ein Ziel, das zu deiner Compose-Konfiguration passt. Wichtig ist, dass der Container das tatsächliche Host-Verzeichnis als gemountetes Volume erhält.

Das LinuxServer-Syncthing-Image verwendet dasselbe Modell und dokumentiert separate Datenzuordnungen vom Host zum Container, etwa /path/to/data1:/data1 und /path/to/data2:/data2. Die PUID-/PGID-Zuordnung von Syncthing erklärt ebenfalls, wie die Container-Identität mit dem Besitz des Host-Volumes übereinstimmen sollte.

Erst wenn der Mount korrekt ist, solltest du Besitzrechte und Berechtigungen korrigieren.

Die ursprüngliche Fehlerbehebung enthielt einen Vorschlag wie:

sudo chmod -R 770 /path/to/folder

770 können in manchen Setups geeignet sein, helfen aber nur, wenn Syncthing tatsächlich als Benutzer oder Gruppe ausgeführt wird, der das Verzeichnis gehört oder die der Gruppe angehört, der das Verzeichnis gehört. Die CasaOS-App übergibt PUID und PGID im LinuxServer-Image. Die eigene Dokumentation von LinuxServer besagt, dass der Besitz des Host-Volumes mit der konfigurierten PUID/PGID übereinstimmen sollte.

Überprüfe die IDs, statt den Benutzernamen anzunehmen. casaos reicht aus:

docker exec syncthing id
stat -c '%u:%g %a %n' /real/host/path/to/external-drive

Wenn die numerischen UID/GID nicht übereinstimmen, ändere den Eigentümer oder die Gruppenmitgliedschaft gezielt. Vermeide chmod -R 777; er verschleiert das eigentliche Problem und schwächt die Zugriffskontrolle.

Was der Fehler „Datei vorhanden“ wirklich aussagt

Die Meldung:

mkdir /DATA/Documents/Syncthing/SyncFiles: Datei vorhanden

beweist nicht, dass das endgültige Dev-Dateien Verzeichnis ist das Problem. Syncthing schlägt beim Vorbereiten des Ordnerstamms fehl. Wenn ein übergeordneter Pfad ein Symlink ist oder innerhalb des Containers anders aufgelöst wird, kann die Anwendung auf ein Dateisystemobjekt stoßen, wo sie einen normalen Verzeichnispfad erwartet.

Die schnellste Diagnose besteht daher nicht darin, dasselbe Verzeichnis zu löschen und neu zu erstellen. Vergleiche stattdessen:

der aufgelöste Pfad des Hosts;
der im Container sichtbare Pfad;
die Bind-Mounts des Containers;
die numerischen PUID/PGID mit dem Eigentümer des Zielpfads.

Für eine saubere Ausgangsbasis zeigt die CasaOS-Syncthing-Einrichtung einen normalen Synchronisierungsablauf mit identischen Pfaden, bevor Anpassungen für mehrere Laufwerke vorgenommen werden. Die ZimaOS-App-Plattform ist beim Vergleich alternativer Backup- oder Dateisynchronisierungstools hilfreich. Wenn das Ziel darin besteht, mehrere physische Laufwerke zusammenzuführen, anstatt sie über Symlinks zu verbinden, ist ZimaCube 2 die hardwareseitig auf Speicher ausgerichtete Option.

FAQ

Sollte ich das Problem lösen, indem ich den Eigentümer von root zu casaos ändere?

Nicht allein dadurch. Der Eigentümer ist erst relevant, wenn der Container den tatsächlichen Zielpfad sehen kann. Überprüfe zuerst den Bind-Mount sowie die numerischen PUID/PGID.

Warum funktioniert ein direkter Pfad, während der Symlink zu einem anderen Laufwerk fehlschlägt?

Ein direkter Pfad unter einem in den Container eingebundenen Verzeichnis ist in beiden Dateisystemen vorhanden. Ein Symlink kann zu einem Host-Speicherort aufgelöst werden, der nie in den Container eingebunden wurde, sodass Syncthing einen Pfad hat, den es nicht durchlaufen kann.

Folgt Syncthing symbolischen Links, um das Zielverzeichnis zu synchronisieren?

Nein. Laut der Syncthing-Dokumentation werden symbolische Links niemals verfolgt. Verwende einen echten, für den Syncthing-Prozess sichtbaren Ordnerpfad.

Was sollte ich zuerst ändern?

Löse den Symlink auf, prüfe die Mounts des Syncthing-Containers und binde das tatsächliche Verzeichnis des externen Laufwerks ein. Überprüfe anschließend PUID/PGID und die Berechtigungen.