Viktig slutsats: det här är förmodligen inte ett problem där man ska ”fortsätta ändra chmod tills Syncthing fungerar”. Den starkare indikationen är att mappen fungerar när den finns på en sökväg som Syncthing kan se direkt, men misslyckas när en symbolisk länk går över till en annan fysisk enhet. I CasaOS pekar det först på containerns monterade sökvägar och därefter på UID/GID-behörigheter.
”Jag har redan ställt in behörigheterna hela vägen … det fungerar när jag anger /DATA/AppData/, men inte när länken pekar på en annan fysisk enhet.” Det testresultatet är mer användbart än det ursprungliga behörighetsfelet, eftersom det isolerar felet till lagringssökvägen.
Varför den symboliska länken är det första man bör ifrågasätta
Syncthing behandlar inte en symbolisk länk som ”hoppa till målet och synkronisera det som finns där”. Det dokumenterade beteendet för symboliska länkar i Syncthing är att symboliska länkar kan synkroniseras, men aldrig följs. Mappkonfigurationen förväntar sig också en verklig enhetsspecifik sökväg: sökvägen till Syncthings mapp är den fysiska sökvägen till mappen på hårddisken.
Det gör en sökväg som denna misstänkt:
/DATA/Documents/Syncthing/SyncFiles → symbolisk länk → /some/other/physical/driveOm Syncthing körs i Docker kan värden följa länken, medan containern kanske inte kan se målet alls.
CasaOS Syncthing-appen förklarar varför en andra enhet kan försvinna
Den officiella CasaOS App Store-definitionen för Syncthing är ovanligt hjälpsam här. Dess compose-fil bindmonterar två värdsökvägar i containern:
/DATA/AppData/$AppID/config → /config
/DATA → /DATADu kan verifiera den faktiska volymmappningen i CasaOS Syncthings compose-fil.
Det innebär att ett mål som fysiskt finns tillgängligt under värdens /DATA-träd också bör vara synligt under /DATA i Syncthing-containern. Men om den symboliska länken till slut pekar på en värdmontering utanför det trädet behöver containern en separat bind-montering till den verkliga målplatsen. Med Docker-bindmonteringar måste värdkataloger uttryckligen monteras in i containern.
Use this test to distinguish a path problem from a permission problem
Använd det här testet för att skilja ett sökvägsproblem från ett behörighetsproblem
Kör kontrollerna i den här ordningen. Börja inte med ännu en rekursiv chmod.
1. Lös den riktiga sökvägen på CasaOS-värdenreadlink -f "/DATA/Documents/Syncthing/SyncFiles" /DATAom kommandot returnerar en sökväg utanför
2. Fråga Syncthing-containern om den kan se samma mål
docker exec syncthing ls -ld "/DATA/Documents/Syncthing/SyncFiles"Testa sedan den upplösta målsökvägen om den ska finnas i containern. Om värden kan visa innehållet men containern inte kan det, är behörigheter ännu inte det primära problemet; sökvägen saknas i containerns namnrymd.
3. Inspektera containerns faktiska monteringar
docker inspect syncthingTitta på Monteringar avsnittet. Du bör kunna identifiera källan på värden och målet i containern för enheten som du vill synkronisera.
Den renare lösningen är att bind-montera den riktiga enheten och sedan använda den containersökvägen
Om den externa enheten finns utanför /DATAoch exponera den direkt för Syncthing i stället för att dölja den bakom en symbolisk länk. Konceptuellt ser compose-posten ut så här:
volumes:
- type: bind
source: /real/host/path/to/external-drive
target: /sync-driveKonfigurera sedan sökvägen till Syncthing-mappen explicit, till exempel:
/sync-drive/Dev FilesDet här är ingen magisk sökväg; välj ett mål som överensstämmer med din compose-konfiguration. Det viktiga är att containern får den riktiga katalogen på värden som en monterad volym.
Den uppströms LinuxServer-avbildningen av Syncthing använder samma modell och dokumenterar separata mappningar från värd till container, till exempel /path/to/data1:/data1 och /path/to/data2:/data2. Dess mappning av PUID/PGID för Syncthing förklarar också hur containerns identitet ska överensstämma med ägarskapet för volymen på värden.
Först när monteringen är korrekt bör du åtgärda ägarskap och behörigheter
Den ursprungliga felsökningen innehöll ett förslag i stil med:
sudo chmod -R 770 /path/to/folder770 kan vara lämpliga i vissa konfigurationer, men det hjälper bara om Syncthing faktiskt körs som en användare eller grupp som äger katalogen eller tillhör gruppen som äger den. CasaOS-appen skickar PUID och PGID i LinuxServer-avbildningen. LinuxServers egen dokumentation säger att ägarskapet för volymer på värden ska överensstämma med den konfigurerade PUID/PGID.
Kontrollera ID:n i stället för att anta användarnamnet casaos räcker:
docker exec syncthing id
stat -c '%u:%g %a %n' /real/host/path/to/external-driveOm de numeriska UID/GID-värdena inte stämmer överens ändrar du ägarskap eller gruppmedlemskap på ett avsiktligt sätt. Undvik chmod -R 777; det döljer det verkliga problemet och försvagar åtkomstkontrollen.
Vad felet ”filen finns” egentligen säger
Meddelandet:
mkdir /DATA/Documents/Syncthing/SyncFiles: filen finnsbevisar inte att den slutliga Utvecklingsfiler katalogen är problemet. Syncthing misslyckas när den förbereder mappens rot. När en överordnad sökväg är en symbolisk länk eller löses annorlunda inuti containern kan programmet stöta på ett filsystemobjekt där det förväntade sig en normal katalogsökväg.
Den snabbaste diagnostiken är därför inte att ta bort och återskapa samma katalog. Det är att jämföra:
- värdens upplösta sökväg;
- sökvägen som är synlig inuti containern;
- containerns bindmonteringar;
- de numeriska PUID/PGID-värdena mot målkatalogens ägarskap.
För en ren utgångspunkt visar CasaOS-konfigurationen för Syncthing ett normalt synkroniseringsflöde med samma sökväg innan anpassning för flera enheter. Appplattformen i ZimaOS är användbar vid jämförelse av alternativa verktyg för säkerhetskopiering eller filsynkronisering. Om målet är att slå samman flera fysiska enheter i stället för att länka mellan dem via symboliska länkar är ZimaCube 2 det lagringsfokuserade hårdvarualternativet.
Vanliga frågor
Bör jag lösa detta genom att ändra ägaren från root till casaos?
Inte i sig. Ägarskapet spelar bara roll efter att containern kan se den faktiska målsökvägen. Kontrollera först bindmonteringen och de numeriska PUID/PGID-värdena.
Varför fungerar en direkt sökväg medan den symboliska länken till en annan enhet misslyckas?
En direkt sökväg under en katalog som monterats i containern finns i båda filsystemen. En symbolisk länk kan lösas till en värdssökväg som aldrig monterades i containern, vilket gör att Syncthing får en sökväg som den inte kan gå igenom.
Följer Syncthing symboliska länkar för att synkronisera målkatalogen?
Nej. Syncthings dokumentation säger att symboliska länkar aldrig följs. Använd en riktig mappsökväg som är synlig för Syncthing-processen.
Vad bör jag ändra först?
Lös den symboliska länken, granska Syncthing-containerns monteringar och bindmontera den faktiska katalogen på den externa enheten. Kontrollera sedan PUID/PGID och behörigheterna.
