Belangrijkste conclusie: dit is waarschijnlijk geen probleem waarbij je “chmod moet blijven aanpassen totdat Syncthing werkt”. Het sterkere signaal is dat de map werkt wanneer deze zich op een pad bevindt dat Syncthing rechtstreeks kan zien, maar niet wanneer een symbolische link naar een andere fysieke schijf gaat. In CasaOS wijst dat eerst op de gemounte paden van de container en vervolgens op de UID/GID-machtigingen.
“Ik heb de machtigingen al volledig ingesteld… het werkt wanneer ik /DATA/AppData/ als doel instel, maar niet wanneer de link naar een andere fysieke schijf verwijst.” Dat testresultaat is nuttiger dan de oorspronkelijke machtigingsfout, omdat het de oorzaak beperkt tot het opslagpad.
Waarom je symbolische links als eerste moet onderzoeken
Syncthing behandelt een symlink niet als “ga naar het doel en synchroniseer wat daar staat”. Volgens het gedocumenteerde gedrag van Syncthing met symlinks kunnen symbolische links wel worden gesynchroniseerd, maar worden ze nooit gevolgd. De mapconfiguratie verwacht bovendien een echt apparaatspecifiek pad: het Syncthing-mappad is het fysieke pad naar de map op de harde schijf.
Dat maakt een pad als dit verdacht:
/DATA/Documents/Syncthing/SyncFiles → symlink → /some/other/physical/driveAls Syncthing in Docker draait, kan de host die link oplossen, terwijl de container de bestemming mogelijk helemaal niet kan zien.
De CasaOS Syncthing-app verklaart waarom een tweede schijf kan verdwijnen
De officiële CasaOS App Store-definitie voor Syncthing is hier ongewoon behulpzaam. Het composebestand mount twee hostpaden als bind mounts in de container:
/DATA/AppData/$AppID/config → /config
/DATA → /DATAJe kunt de daadwerkelijke volumekoppeling controleren in de CasaOS Syncthing-composeconfiguratie.
Dat betekent dat een doel dat fysiek beschikbaar is binnen de /DATA-structuur van de host, ook zichtbaar moet zijn onder /DATA in de Syncthing-container. Maar als de symlink uiteindelijk verwijst naar een hostkoppelpunt buiten die structuur, heeft de container een aparte bind mount naar de echte bestemming nodig. Met Docker-bind mounts moeten hostmappen expliciet in de container worden gemount.
Gebruik deze test om een padprobleem van een rechtenprobleem te onderscheiden
Voer de controles in deze volgorde uit. Begin niet met nog een recursieve chmod.
1. Los het echte pad op de CasaOS-host op
readlink -f "/DATA/Documents/Syncthing/SyncFiles"Als de opdracht een pad buiten /DATA, dan heb je een belangrijke aanwijzing gevonden.
2. Vraag de Syncthing-container of deze dezelfde bestemming kan zien
docker exec syncthing ls -ld "/DATA/Documents/Syncthing/SyncFiles"Test vervolgens de opgeloste bestemming als die in de container zou moeten bestaan. Als de host de map kan weergeven maar de container niet, zijn rechten nog niet het primaire probleem; het pad ontbreekt in de containernamespace.
3. Inspecteer de daadwerkelijke containermounts
docker inspect syncthingBekijk de Mounts sectie. Je zou de hostbron en containerbestemming moeten kunnen identificeren voor de schijf die je wilt synchroniseren.
De betere oplossing: koppel de echte schijf met bind-mount en gebruik vervolgens dat containerpad
Als de externe schijf zich buiten /DATA, koppel het rechtstreeks aan Syncthing in plaats van het achter een symbolische link te verbergen. Conceptueel ziet de compose-vermelding er als volgt uit:
volumes:
- type: bind
source: /real/host/path/to/external-drive
target: /sync-driveConfigureer daarna het Syncthing-mappad expliciet, bijvoorbeeld:
/sync-drive/Dev FilesDit is geen magisch pad; kies een doel dat overeenkomt met je compose-configuratie. Het belangrijkste is dat de container de echte hostmap als een gekoppeld volume ontvangt.
De upstream LinuxServer Syncthing-image gebruikt hetzelfde model en documenteert afzonderlijke gegevenskoppelingen van host naar container, zoals /path/to/data1:/data1 en /path/to/data2:/data2. De Syncthing PUID/PGID-koppeling legt ook uit hoe de containeridentiteit moet overeenkomen met het eigendom van hostvolumes.
Pas nadat de mount correct is, moet je het eigendom en de rechten herstellen
De oorspronkelijke probleemoplossing bevatte een suggestie zoals:
sudo chmod -R 770 /path/to/folder770 kunnen in sommige configuraties geschikt zijn, maar het helpt alleen als Syncthing daadwerkelijk draait als een gebruiker of groep die eigenaar is van die map, of lid is van de groep die eigenaar is. De CasaOS-app geeft PUID en PGID in de LinuxServer-image. In de eigen documentatie van LinuxServer staat dat het eigendom van hostvolumes moet overeenkomen met de geconfigureerde PUID/PGID.
Controleer de ID's in plaats van de gebruikersnaam te veronderstellen casaos is voldoende:
docker exec syncthing id
stat -c '%u:%g %a %n' /real/host/path/to/external-driveAls de numerieke UID/GID niet overeenkomen, wijzig dan bewust het eigenaarschap of het groepslidmaatschap. Vermijd chmod -R 777; dit verbergt het echte probleem en verzwakt de toegangscontrole.
Wat de foutmelding 'bestand bestaat al' werkelijk betekent
De melding:
mkdir /DATA/Documents/Syncthing/SyncFiles: bestand bestaat albewijst niet dat de uiteindelijke Ontwikkelaarsbestanden de map is het probleem. Syncthing faalt bij het voorbereiden van de hoofdmap. Wanneer een bovenliggende map een symbolische koppeling is of binnen de container anders wordt opgelost, kan de toepassing een bestandssysteemobject tegenkomen waar ze een normaal mappad verwachtte.
De snelste diagnose is daarom niet dezelfde map verwijderen en opnieuw aanmaken. Vergelijk in plaats daarvan:
- het opgeloste pad op de host;
- het pad dat in de container zichtbaar is;
- de bind-mounts van de container;
- de numerieke PUID/PGID met het eigenaarschap van de bestemming.
Voor een schone uitgangssituatie laat de CasaOS Syncthing-installatie een normale synchronisatiestroom met hetzelfde pad zien, voordat je aanpassingen voor meerdere schijven uitvoert. Het ZimaOS-appplatform is handig bij het vergelijken van alternatieve back-up- of bestandssynchronisatietools. Als het einddoel is om meerdere fysieke schijven te combineren in plaats van ze via symbolische koppelingen te verbinden, is ZimaCube 2 de hardwareoptie die op opslag is gericht.
Veelgestelde vragen
Moet ik dit oplossen door de eigenaar van root in casaos te veranderen?
Niet op zichzelf. Eigenaarschap is pas van belang nadat de container het echte doelpad kan zien. Controleer eerst de bind-mount en de numerieke PUID/PGID.
Waarom werkt een rechtstreeks pad wel, maar mislukt een symbolische koppeling naar een andere schijf?
Een rechtstreeks pad onder een map die in de container is gemount, bestaat in beide bestandssystemen. Een symbolische koppeling kan verwijzen naar een locatie op de host die nooit in de container is gemount, waardoor Syncthing een pad heeft waar het niet doorheen kan navigeren.
Volgt Syncthing symbolische koppelingen om de doelmap te synchroniseren?
Nee. In de documentatie van Syncthing staat dat symbolische koppelingen nooit worden gevolgd. Gebruik een echt mappad dat zichtbaar is voor het Syncthing-proces.
Wat moet ik als eerste wijzigen?
Los de symbolische koppeling op, controleer de mounts van de Syncthing-container en koppel de daadwerkelijke map op de externe schijf rechtstreeks. Controleer daarna de PUID/PGID en de rechten.
