Syncthing w CasaOS synchronizuje pliki, ale nie może ich usuwać ani modyfikować

Najważniejszy wniosek: jeśli Syncthing może odczytywać folder, ale nie może propagować usunięć ani modyfikacji, sprawdź uprawnienia zapisu z wnętrza kontenera Syncthing. Montowanie bind, które można odczytywać, nie jest automatycznie zapisywalne.

Najpierw sprawdź tryb folderu

Folder dwukierunkowy powinien używać trybów folderów Syncthing odpowiednich do odbierania zmian. Tryb „Tylko wysyłanie” nie będzie działać tak jak „Wysyłanie i odbieranie”.

Sprawdź, czy kontener może zapisywać

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

Jeśli którekolwiek polecenie zakończy się niepowodzeniem, napraw uprawnienia do pamięci masowej przed zmianą ustawień Syncthing.

Dopasuj PUID i PGID

Oficjalny plik compose Syncthing dla CasaOS przekazuje PUID/PGID i podpina /DATA do kontenera. Firma LinuxServer wyjaśnia własność PUID/PGID woluminów hosta.

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

Porównaj identyfikatory liczbowe. Zmiana właściciela na nazwę użytkownika nie wystarczy, jeśli kontener działa z innym UID/GID.

Usuwanie wymaga uprawnień do katalogu nadrzędnego

Usunięcie lub zmiana nazwy pliku wymaga uprawnień zapisu i wykonywania w katalogu nadrzędnym. Wyjaśnia to, dlaczego odczyt/synchronizacja może działać częściowo, podczas gdy zdalne usuwanie kończy się niepowodzeniem.

Porównaj działający folder

Porównaj docker inspect syncthing punktów montowania, stat trybu/UID/GID, list ACL za pomocą getfacl, stan systemu plików tylko do odczytu oraz wzorce ignorowania. Nie przechodź od razu do chmod 777.

Konfiguracja Syncthing w CasaOS zapewnia dobry punkt odniesienia. Platforma aplikacji ZimaOS ułatwia porównywanie alternatyw, a ZimaCube 2 sprawdzi się w przypadku magazynów wielodyskowych.

Sprawdź listy ACL, gdy bity trybu Unix wyglądają poprawnie

Tradycyjne chmod wynik może wyglądać poprawnie, mimo że ACL nadal zmienia efektywne uprawnienia. Porównaj działający i niesprawny katalog:

getfacl /DATA/Gallery
getfacl /DATA/Documents

Jeśli jedna ze ścieżek zawiera dodatkowe wpisy ACL, napraw je celowo, zamiast rekurencyjnie otwierać uprawnienia wszędzie.

Sprawdź, czy system plików jest zamontowany tylko do odczytu

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

Dysk zamontowany jako ro, błędy systemu plików lub niesprawny dysk zewnętrzny mogą powodować ten sam objaw „można odczytywać, ale nie można wprowadzać zmian”. Jeśli samo montowanie jest tylko do odczytu, zmiana ustawień Syncthing nie rozwiąże problemu.

Odczytaj błąd Syncthing kryjący się za komunikatem „niesynchronizowane”

Otwórz interfejs webowy Syncthing i sprawdź błąd folderu, a następnie porównaj dzienniki kontenera:

docker logs --tail 200 syncthing

Sprawdź odmowa dostępu, operacja niedozwolona, błędy nieznalezionej ścieżki lub nieudane operacje zmiany nazwy/usuwania. „Niesynchronizowane” to stan; dziennik zwykle zawiera przyczynę problemu na niższym poziomie systemu plików.

Nie używaj opcji „Ignoruj uprawnienia” jako uniwersalnego rozwiązania

Ignorowanie metadanych uprawnień może pomóc, gdy dwa systemy plików różnie reprezentują bity trybu Unix, ale nie nadaje ono procesowi uprawnień do zapisu. Jeśli kontener nie może usunąć pliku testowego, zmiana sposobu obsługi metadanych uprawnień przez Syncthing nie sprawi, że katalog na hoście stanie się zapisywalny.

Użyj kontrolowanego testu zapisu

Utwórz mały, tymczasowy katalog, zamontuj go w Syncthingu i sprawdź operacje utworzenia → edycji → zmiany nazwy → usunięcia na obu urządzeniach. Gdy to zadziała, zastosuj ten sam schemat właściciela i montowania do rzeczywistego folderu. Pozwoli to odseparować działanie synchronizacji od skomplikowanego, istniejącego drzewa katalogów.

FAQ

Dlaczego Syncthing może dodawać pliki, ale nie może ich usuwać?

Uprawnienia katalogu nadrzędnego mogą zezwalać na odczyt, ale blokować operacje zmiany nazwy i usuwania.

Czy powinienem użyć chmod 777?

Nie. Najpierw potwierdź ścieżkę powodującą błąd i tożsamość kontenera.