Viktig slutsats: om Syncthing kan läsa en mapp men inte sprida borttagningar eller ändringar, testa skrivbehörigheten inifrån Syncthing-containern. En läsbar bind-montering är inte automatiskt skrivbar.
Kontrollera mappsläget först
En dubbelriktad mapp bör använda Syncthing-mappslägen som är lämpliga för att ta emot ändringar. Endast sändning fungerar inte som Skicka och ta emot.
Bevisa att containern kan skriva
docker exec -it syncthing sh
touch /DATA/Gallery/.write-test
rm /DATA/Gallery/.write-testOm något av kommandona misslyckas åtgärdar du lagringsbehörigheterna innan du ändrar Syncthing-inställningarna.
Matcha PUID och PGID
Den officiella CasaOS Syncthing Compose-konfigurationen skickar med PUID/PGID och binder /DATA till containern. LinuxServer förklarar PUID/PGID-ägarskap för volymer på värden.
docker exec syncthing id
stat -c '%u:%g %a %n' /DATA/GalleryJämför numeriska ID:n. Det räcker inte att ändra ägarskapet till ett användarnamn om containern körs med ett annat UID/GID.
Borttagningar kräver rättigheter för den överordnade mappen
Att ta bort eller byta namn på en fil kräver skriv- och körbehörighet för den överordnade mappen. Det förklarar varför läsning/synkronisering kan verka fungera delvis medan fjärrborttagningar misslyckas.
Jämför en fungerande mapp
Jämför docker inspect syncthing monteringar, stat läge/UID/GID, ACL:er med getfacl, filsystemets skrivskyddade status och ignoreringsmönster. Hoppa inte direkt till chmod 777.
CasaOS Syncthing-installationen ger en ren utgångspunkt. ZimaOS-appplattformen gör det enklare att jämföra alternativ, medan ZimaCube 2 passar arbetsbelastningar med lagring på flera enheter.
Kontrollera ACL:er när Unix-behörighetsbitarna ser korrekta ut
Traditionella chmod utdata kan se korrekt ut samtidigt som en ACL fortfarande ändrar de effektiva behörigheterna. Jämför en fungerande och en felande katalog:
getfacl /DATA/Gallery
getfacl /DATA/DocumentsOm en sökväg innehåller extra ACL-poster åtgärdar du dem avsiktligt i stället för att rekursivt öppna behörigheterna överallt.
Kontrollera om filsystemet är skrivskyddat
findmnt -no TARGET,SOURCE,FSTYPE,OPTIONS /DATA/GalleryEn disk monterad ro, filsystemfel eller en försämrad extern enhet kan ge samma symtom: ”kan läsa men kan inte ändra”. Om monteringen i sig är skrivskyddad kan ändringar i Syncthings inställningar inte lösa det.
Läs Syncthing-felet bakom ”inte synkroniserad”
Öppna Syncthings webbgränssnitt och kontrollera mappfelet. Jämför sedan containerloggarna:
docker logs --tail 200 syncthingLeta efter åtkomst nekas, åtgärden tillåts inte, fel där sökvägen inte hittas eller misslyckade åtgärder för att byta namn eller radera. ”Inte synkroniserad” är ett tillstånd; loggen innehåller vanligtvis den underliggande orsaken i filsystemet.
Använd inte Ignorera behörigheter som en universallösning
Att ignorera behörighetsmetadata kan hjälpa när två filsystem representerar Unix-behörighetsbitar på olika sätt, men det ger inte processen skrivbehörighet. Om containern inte kan radera en testfil gör en ändring av Syncthings beteende för behörighetsmetadata inte värdkatalogen skrivbar.
Använd ett kontrollerat skrivtest
Skapa en liten, tillfällig katalog, mappa in den i Syncthing och verifiera skapa → redigera → byt namn → radera från båda enheterna. När det fungerar tillämpar du samma ägar- och monteringsmönster på den riktiga mappen. På så sätt separeras synkroniseringsbeteendet från ett komplicerat befintligt katalogträd.
Vanliga frågor
Varför kan Syncthing lägga till men inte radera?
Behörigheter för överordnade kataloger kan tillåta läsning men blockera åtgärder som att byta namn eller radera.
Bör jag använda chmod 777?
Nej. Bevisa först den felande sökvägen och containerns identitet.
