Belangrijkste conclusie: als Syncthing een map kan lezen maar verwijderingen of wijzigingen niet kan doorvoeren, test dan de schrijfrechten vanuit de Syncthing-container. Een leesbare bind-mount is niet automatisch beschrijfbaar.
Controleer eerst de mapmodus
Een bidirectionele map moet geschikte Syncthing-mapmodi gebruiken voor het ontvangen van wijzigingen. Alleen verzenden werkt niet zoals Verzenden & ontvangen.
Bewijs dat de container kan schrijven
docker exec -it syncthing sh
touch /DATA/Gallery/.write-test
rm /DATA/Gallery/.write-testAls een van beide opdrachten mislukt, los dan de opslagrechten op voordat je de Syncthing-instellingen wijzigt.
Stem PUID en PGID op elkaar af
De officiële CasaOS Syncthing Compose-configuratie geeft PUID/PGID door en koppelt /DATA aan de container. LinuxServer legt PUID/PGID-eigendom voor hostvolumes uit.
docker exec syncthing id
stat -c '%u:%g %a %n' /DATA/GalleryVergelijk de numerieke ID's. Het wijzigen van het eigendom naar een gebruikersnaam is niet voldoende als de container onder een andere UID/GID draait.
Voor verwijderingen zijn rechten op de bovenliggende map nodig
Voor het verwijderen of hernoemen van een bestand zijn schrijf- en uitvoeringsrechten op de bovenliggende map vereist. Dat verklaart waarom lezen/synchroniseren gedeeltelijk kan werken terwijl externe verwijderingen mislukken.
Vergelijk een werkende map
Vergelijk docker inspect syncthing mounts, stat modus/UID/GID, ACL's met getfacl, alleen-lezenstatus van het bestandssysteem en negeerpatronen. Ga niet meteen over op chmod 777.
De CasaOS Syncthing-configuratie biedt een schone basis. Het ZimaOS-appplatform helpt alternatieven te vergelijken, terwijl ZimaCube 2 geschikt is voor opslag met meerdere schijven.
Controleer de ACL's wanneer de Unix-modusbits correct lijken
Traditioneel chmod de uitvoer kan er goed uitzien terwijl een ACL de effectieve rechten nog steeds wijzigt. Vergelijk een werkende en een falende map:
getfacl /DATA/Gallery
getfacl /DATA/DocumentsAls een pad extra ACL-vermeldingen bevat, los die dan bewust op in plaats van overal recursief de rechten open te zetten.
Controleer of het bestandssysteem alleen-lezen is
findmnt -no TARGET,SOURCE,FSTYPE,OPTIONS /DATA/GalleryEen schijf aangekoppeld als ro, bestandssysteemfouten of een defecte externe schijf kunnen hetzelfde symptoom veroorzaken: ‘kan wel lezen maar niets wijzigen’. Als de koppeling zelf alleen-lezen is, kunnen Syncthing-instellingen dit niet oplossen.
Lees de Syncthing-fout achter ‘niet gesynchroniseerd’
Open de webinterface van Syncthing en bekijk de mapfout. Vergelijk vervolgens de containerlogboeken:
docker logs --tail 200 syncthingZoek naar toegang geweigerd, bewerking niet toegestaan, fouten waarbij het pad niet wordt gevonden of mislukte hernoem- en verwijderbewerkingen. ‘Niet gesynchroniseerd’ is een status; het logboek bevat meestal de onderliggende oorzaak op bestandssysteemniveau.
Gebruik ‘Rechten negeren’ niet als universele oplossing
Het negeren van rechtenmetadata kan helpen wanneer twee bestandssystemen Unix-modusbits verschillend weergeven, maar het verleent het proces geen schrijfrechten. Als de container een testbestand niet kan verwijderen, maakt het wijzigen van het gedrag van Syncthing voor rechtenmetadata de map op de host niet schrijfbaar.
Gebruik een gecontroleerde schrijftest
Maak een kleine tijdelijke map, koppel die aan Syncthing en controleer op beide apparaten het aanmaken → bewerken → hernoemen → verwijderen. Pas dezelfde eigenaars- en koppelingsconfiguratie toe op de echte map zodra dat werkt. Zo scheid je het synchronisatiegedrag van een ingewikkelde bestaande mappenstructuur.
Veelgestelde vragen
Waarom kan Syncthing wel toevoegen maar niet verwijderen?
Rechten op de bovenliggende map kunnen lezen toestaan, maar het hernoemen/verwijderen blokkeren.
Moet ik chmod 777 gebruiken?
Nee. Toon eerst het falende pad en de identiteit van de container aan.
