Najważniejszy wniosek: prawdopodobnie nie jest to problem typu „ciągle zmieniaj chmod, aż Syncthing zadziała”. Silniejszy sygnał wskazuje, że folder działa, gdy znajduje się w ścieżce, którą Syncthing widzi bezpośrednio, ale przestaje działać, gdy dowiązanie symboliczne prowadzi na inny dysk fizyczny. W CasaOS wskazuje to najpierw na ścieżki zamontowane w kontenerze, a następnie na uprawnienia UID/GID.
„Nadałem już uprawnienia na całej ścieżce… działa, gdy wskazuję /DATA/AppData/, ale nie działa, gdy dowiązanie wskazuje na inny dysk fizyczny.” Ten wynik testu jest bardziej przydatny niż pierwotny błąd uprawnień, ponieważ ogranicza źródło problemu do ścieżki pamięci masowej.
Dlaczego dowiązanie symboliczne jest pierwszą rzeczą, którą należy sprawdzić
Syncthing nie traktuje dowiązania symbolicznego jako polecenia „przejdź do celu i synchronizuj wszystko, co się tam znajduje”. Zgodnie z udokumentowanym zachowaniem dowiązań symbolicznych w Syncthing dowiązania symboliczne mogą być synchronizowane, ale nigdy nie są śledzone. Konfiguracja folderu również oczekuje rzeczywistej ścieżki lokalnej dla urządzenia: Ścieżka folderu Syncthing to fizyczna ścieżka do folderu na dysku twardym.
To sprawia, że taka ścieżka budzi podejrzenia:
/DATA/Documents/Syncthing/SyncFiles → dowiązanie symboliczne → /some/other/physical/driveJeśli Syncthing działa w Dockerze, host może rozwiązać to dowiązanie, podczas gdy kontener może w ogóle nie widzieć miejsca docelowego.
Aplikacja Syncthing w CasaOS wyjaśnia, dlaczego drugi dysk może zniknąć
Oficjalna definicja Syncthing w CasaOS App Store jest tutaj wyjątkowo pomocna. Jej plik compose montuje bind dwa katalogi hosta w kontenerze:
/DATA/AppData/$AppID/config → /config
/DATA → /DATARzeczywiste mapowanie woluminów możesz sprawdzić w pliku compose Syncthing dla CasaOS.
Oznacza to, że miejsce docelowe fizycznie dostępne w drzewie hosta /DATA powinno być również widoczne pod /DATA wewnątrz kontenera Syncthing. Jeśli jednak dowiązanie symboliczne ostatecznie wskazuje na zamontowany w hoście zasób znajdujący się poza tym drzewem, kontener potrzebuje osobnego montowania bind dla rzeczywistego miejsca docelowego. W przypadku montowań bind Docker katalogi hosta muszą być jawnie zamontowane w kontenerze.
Użyj tego testu, aby odróżnić problem ze ścieżką od problemu z uprawnieniami
Wykonaj kontrole w tej kolejności. Nie zaczynaj od kolejnego rekurencyjnego chmod.
1. Rozwiąż rzeczywistą ścieżkę na hoście CasaOS
readlink -f "/DATA/Documents/Syncthing/SyncFiles"Jeśli polecenie zwraca ścieżkę poza /DATA, znalazłeś ważną wskazówkę.
2. Zapytaj kontener Syncthing, czy widzi ten sam cel
docker exec syncthing ls -ld "/DATA/Documents/Syncthing/SyncFiles"Następnie przetestuj rozwiązaną ścieżkę docelową, jeśli powinna istnieć wewnątrz kontenera. Jeśli host może ją wyświetlić, ale kontener nie, uprawnienia nie są jeszcze głównym problemem — ścieżki brakuje w przestrzeni nazw kontenera.
3. Sprawdź rzeczywiste montowania kontenera
docker inspect syncthingSpójrz na Montowania sekcję. Powinno być możliwe zidentyfikowanie źródła na hoście i miejsca docelowego w kontenerze dla dysku, który ma być synchronizowany.
Lepsze rozwiązanie: zamontuj rzeczywisty dysk za pomocą bind mount, a następnie użyj tej ścieżki w kontenerze
Jeśli dysk zewnętrzny znajduje się poza /DATA, udostępniając go bezpośrednio Syncthing zamiast ukrywać go za dowiązaniem symbolicznym. W uproszczeniu wpis Compose wygląda tak:
volumes:
- type: bind
source: /real/host/path/to/external-drive
target: /sync-driveNastępnie skonfiguruj ścieżkę folderu Syncthing jako coś jednoznacznego, na przykład:
/sync-drive/Dev FilesNie jest to magiczna ścieżka — wybierz miejsce docelowe pasujące do konfiguracji Compose. Najważniejsze jest to, aby kontener otrzymał rzeczywisty katalog hosta jako zamontowany wolumin.
Obraz Syncthing firmy LinuxServer korzysta z tego samego modelu i opisuje oddzielne mapowania danych host–kontener, takie jak /path/to/data1:/data1 i /path/to/data2:/data2. Jego mapowanie PUID/PGID w Syncthing wyjaśnia również, jak tożsamość kontenera powinna odpowiadać właścicielstwu woluminu hosta.
Dopiero gdy montowanie jest poprawne, należy naprawić właścicielstwo i uprawnienia
W pierwotnych wskazówkach dotyczących rozwiązywania problemów znajdowała się sugestia w rodzaju:
sudo chmod -R 770 /path/to/folder770 mogą być odpowiednie w niektórych konfiguracjach, ale pomagają tylko wtedy, gdy Syncthing rzeczywiście działa jako użytkownik lub grupa będąca właścicielem tego katalogu albo należąca do grupy, która jest jego właścicielem. Aplikacja CasaOS przekazuje PUID i PGID w obrazie LinuxServer. Własna dokumentacja LinuxServer mówi, że właścicielstwo woluminu hosta powinno odpowiadać skonfigurowanym wartościom PUID/PGID.
Sprawdź identyfikatory zamiast zakładać nazwę użytkownika casaos wystarczy:
docker exec syncthing id
stat -c '%u:%g %a %n' /real/host/path/to/external-driveJeśli numeryczne UID/GID się nie zgadzają, celowo zmień właściciela lub członkostwo w grupie. Unikaj chmod -R 777; ukrywa rzeczywisty problem i osłabia kontrolę dostępu.
Co naprawdę oznacza błąd „plik istnieje”
Komunikat:
mkdir /DATA/Documents/Syncthing/SyncFiles: plik istniejenie dowodzi, że końcowy Pliki deweloperskie katalog jest problemem. Syncthing nie działa poprawnie podczas przygotowywania katalogu głównego folderu. Gdy ścieżka nadrzędna jest dowiązaniem symbolicznym lub wewnątrz kontenera rozwiązuje się inaczej, aplikacja może napotkać obiekt systemu plików tam, gdzie oczekiwała zwykłej ścieżki katalogu.
Najszybsza diagnostyka nie polega więc na usuwaniu i ponownym tworzeniu tego samego katalogu. Polega na porównaniu:
- rozwiązaną ścieżkę na hoście;
- ścieżkę widoczną wewnątrz kontenera;
- montowania bind kontenera;
- numeryczne PUID/PGID z właścicielem katalogu docelowego.
Aby uzyskać czystą bazę, konfiguracja Syncthing w CasaOS pokazuje standardowy przebieg synchronizacji z tą samą ścieżką przed dostosowaniem do wielu dysków. Platforma aplikacji ZimaOS jest przydatna podczas porównywania alternatywnych narzędzi do tworzenia kopii zapasowych lub synchronizacji plików. Jeśli celem jest połączenie kilku fizycznych dysków zamiast przekierowywania ich przez dowiązania symboliczne, ZimaCube 2 to sprzętowa opcja skoncentrowana na pamięci masowej.
Często zadawane pytania
Czy powinienem rozwiązać ten problem, zmieniając właściciela z root na casaos?
Nie samo w sobie. Właściciel ma znaczenie dopiero wtedy, gdy kontener może zobaczyć rzeczywistą ścieżkę docelową. Najpierw zweryfikuj montowanie bind oraz numeryczne PUID/PGID.
Dlaczego bezpośrednia ścieżka działa, a dowiązanie symboliczne do innego dysku kończy się niepowodzeniem?
Bezpośrednia ścieżka pod katalogiem zamontowanym w kontenerze istnieje w obu systemach plików. Dowiązanie symboliczne może wskazywać lokalizację hosta, która nigdy nie została zamontowana w kontenerze, przez co Syncthing otrzymuje ścieżkę, której nie może przeszukać.
Czy Syncthing śledzi dowiązania symboliczne w celu synchronizowania katalogu docelowego?
Nie. Dokumentacja Syncthing mówi, że dowiązania symboliczne nigdy nie są śledzone. Użyj rzeczywistej ścieżki folderu widocznej dla procesu Syncthing.
Co powinienem zmienić najpierw?
Rozwiąż dowiązanie symboliczne, sprawdź montowania kontenera Syncthing i zamontuj przez bind właściwy katalog na dysku zewnętrznym. Następnie zweryfikuj PUID/PGID oraz uprawnienia.
