CasaOS Syncthing: Synchronisierte Dateien können nicht gelöscht oder geändert werden

Wichtige Schlussfolgerung: Wenn Syncthing einen Ordner lesen, aber Löschungen oder Änderungen nicht weitergeben kann, testen Sie die Schreibberechtigung innerhalb des Syncthing-Containers. Ein lesbarer Bind-Mount ist nicht automatisch beschreibbar.

Zuerst den Ordnermodus prüfen

Ein bidirektionaler Ordner sollte Syncthing-Ordner-Modi verwenden, die für den Empfang von Änderungen geeignet sind. „Nur senden“ verhält sich nicht wie „Senden und empfangen“.

Nachweisen, dass der Container schreiben kann

docker exec -it syncthing sh
touch /DATA/Gallery/.write-test
rm /DATA/Gallery/.write-test

Wenn einer der beiden Befehle fehlschlägt, beheben Sie die Speicherberechtigungen, bevor Sie die Syncthing-Einstellungen ändern.

Screenshot eines CasaOS-Syncthing-Ordnerfehlers, der zeigt, dass ein Ordner fehlschlägt, während benachbarte Ordner funktionieren — Wenn ein Ordner fehlschlägt, während benachbarte Ordner funktionieren, vergleichen Sie den genauen Pfad und den Besitz.

Screenshot des CasaOS-Speicherpfads zum Vergleich der Syncthing-Ordnerzuordnungen — Verwenden Sie einen funktionierenden Ordner als Referenz, wenn Sie die Einhängepfade vergleichen.

PUID und PGID abgleichen

Das offizielle CasaOS-Syncthing-Compose-Setup übergibt PUID/PGID und bindet /DATA in den Container ein. LinuxServer erläutert PUID/PGID-Besitz für Host-Volumes.

docker exec syncthing id
stat -c '%u:%g %a %n' /DATA/Gallery

Vergleichen Sie die numerischen IDs. Das Ändern des Besitzes auf einen Benutzernamen reicht nicht aus, wenn der Container unter einer anderen UID/GID ausgeführt wird.

Zum Löschen sind Berechtigungen für das übergeordnete Verzeichnis erforderlich

Das Entfernen oder Umbenennen einer Datei erfordert Schreib- und Ausführungsberechtigungen für das übergeordnete Verzeichnis. Das erklärt, warum Lesen/Synchronisieren teilweise funktionieren kann, während das Löschen aus der Ferne fehlschlägt.

Hervorgehobener Speicherort des CasaOS-Anwendungsprotokolls zur Fehlerbehebung bei Syncthing — Verwenden Sie Protokolle zusammen mit direkten Tests des Dateisystems.

Nicht synchronisierter Syncthing-Zustand, nachdem ein entferntes Gerät Dateien auf einem CasaOS-Host geändert hat — Ein nicht synchronisierter Zustand nach Änderungen auf dem entfernten Gerät weist auf den Schreibpfad der empfangenden Seite hin.

Einen funktionierenden Ordner vergleichen

Vergleichen docker inspect syncthing Einhängungen, stat Modus/UID/GID, ACLs mit getfacl, schreibgeschützter Dateisystemstatus und Ignoriermuster. Fahren Sie nicht direkt fort zu chmod 777.

Die CasaOS-Syncthing-Einrichtung bietet eine klare Ausgangsbasis. Die ZimaOS-App-Plattform erleichtert den Vergleich von Alternativen, während sich ZimaCube 2 für Speicher-Workloads mit mehreren Laufwerken eignet.

Prüfe die ACLs, wenn die Unix-Modusbits korrekt aussehen

Traditionell chmod Die Ausgabe kann unauffällig aussehen, während eine ACL weiterhin die effektiven Berechtigungen ändert. Vergleiche ein funktionierendes und ein fehlschlagendes Verzeichnis:

getfacl /DATA/Gallery
getfacl /DATA/Documents

Wenn ein Pfad zusätzliche ACL-Einträge enthält, behebe diese gezielt, statt Berechtigungen überall rekursiv zu öffnen.

Prüfe, ob das Dateisystem schreibgeschützt ist

findmnt -no TARGET,SOURCE,FSTYPE,OPTIONS /DATA/Gallery

Eine Festplatte eingebunden als ro, Dateisystemfehler oder ein beeinträchtigtes externes Laufwerk können dasselbe Symptom „kann lesen, aber nicht ändern“ verursachen. Wenn die Einbindung selbst schreibgeschützt ist, können Änderungen an den Syncthing-Einstellungen das Problem nicht beheben.

Lies den Syncthing-Fehler hinter „nicht synchron“

Öffne die Syncthing-Weboberfläche und prüfe den Ordnerfehler. Vergleiche anschließend die Containerprotokolle:

docker logs --tail 200 syncthing

Suche nach Zugriff verweigert, Vorgang nicht zulässig, Fehlern wegen nicht gefundener Pfade oder fehlgeschlagenen Umbenennungs-/Löschvorgängen. „Nicht synchron“ ist ein Zustand; das Protokoll enthält normalerweise die tieferliegende Ursache auf Dateisystemebene.

Verwende „Berechtigungen ignorieren“ nicht als universelle Lösung

Das Ignorieren von Berechtigungsmetadaten kann hilfreich sein, wenn zwei Dateisysteme Unix-Modusbits unterschiedlich darstellen, gewährt dem Prozess jedoch keine Schreibberechtigung. Wenn der Container eine Testdatei nicht löschen kann, wird das Ändern des Verhaltens von Syncthing bei Berechtigungsmetadaten das Hostverzeichnis nicht beschreibbar machen.

Führe einen kontrollierten Schreibtest durch

Erstelle ein kleines, entbehrliches Verzeichnis, binde es in Syncthing ein und überprüfe Erstellen → Bearbeiten → Umbenennen → Löschen auf beiden Geräten. Sobald das funktioniert, übertrage dasselbe Besitz- und Einbindungsmuster auf den tatsächlichen Ordner. So lässt sich das Synchronisierungsverhalten von einem komplexen bestehenden Verzeichnisbaum isolieren.

FAQ

Warum kann Syncthing Dateien hinzufügen, aber nicht löschen?

Berechtigungen des übergeordneten Verzeichnisses können das Lesen erlauben, aber das Umbenennen/Löschen verhindern.

Soll ich chmod 777 verwenden?

Nein. Belege zuerst den fehlschlagenden Pfad und die Identität des Containers.