De brongebruiker had Syncthing werkend voor het synchroniseren van telefoonfoto’s, maar de bestanden kwamen steeds op de systeemschijf terecht in plaats van op de opslagschijf. Door een pad uit de Bestanden-app te kopiëren en dat rechtstreeks in Syncthing te plakken, liet de gebruiker Syncthing dezelfde ogende mappenstructuur opnieuw aanmaken in het eigen bestandssysteem van de container.
De uiteindelijke oplossing was conceptueel en geen magisch bestandssysteemcommando: Docker heeft een hostpad en een containerpad. Syncthing moet het pad gebruiken dat in de container zichtbaar is, niet het onbewerkte pad dat zichtbaar is in CasaOS of ZimaOS.
Waarom het externe pad op de verkeerde plaats opnieuw werd aangemaakt
Als Syncthing wordt verteld een pad te gebruiken dat het niet daadwerkelijk kan zien, kan het dat pad aanmaken in zijn eigen beschrijfbare bestandssysteem of in een toegewezen configuratielocatie. De brongebruiker interpreteerde de mapnaam als een pad naar de externe schijf, terwijl de container deze interpreteerde als een pad relatief aan zijn eigen bestandssysteem.
Vind het echte mountpunt van de host
De community gebruikte lsblk om vast te stellen waar het besturingssysteem de externe schijf had aangekoppeld. In het voorbeeld van de beantwoorder verscheen de schijf onder een pad dat leek op /media/devmon/...; de schijven van de oorspronkelijke poster verschenen later onder /mnt/Storage1 en /mnt/Storage2.
Die exacte historische mountpaden zijn voorbeelden van CasaOS/ZimaBlade en moeten niet worden beschouwd als universele huidige paden in ZimaOS.
Wijs de hostschijf toe aan Syncthing
De beantwoorder gebruikte /DATA als het pad aan de Syncthing-zijde. Zodra die toewijzing bestaat, moet Syncthing verwijzen naar mappen onder /DATA in plaats van het oorspronkelijke mountpad van de host.
De gebruiker voerde aanvankelijk het hostpad in Syncthing in
Syncthing gaf vervolgens een fout over rechten/pad, omdat dat interne pad niet overeenkwam met het toegewezen volume.
Het uiteindelijke werkende pad was /DATA/Documents
De beantwoorder legde uit dat Syncthing, nadat de hostschijf was toegewezen aan /DATAmoet Syncthing het volgende gebruiken:
/DATA/Documentsof het equivalent daarvan ~/Documents afkorting gebruikt wanneer de home-directory van Syncthing naar die toegewezen gegevenslocatie verwijst.
De oorspronkelijke poster kwam de volgende dag terug en bevestigde dat het werkte.
Recursieve chown maakte deel uit van de communityworkflow, niet van de kernoplossing
In de thread werd ook recursieve chown op de externe schijf. Dat kan passend zijn op een bestandssysteem dat door Linux wordt beheerd, maar het wijzigt het eigenaarschap over het volledige doel en was geen door IceWhale opgestelde vereiste.
Voer geen recursieve eigendomswijziging uit op een bestaande gedeelde schijf voordat je weet welke gebruikers en applicaties al afhankelijk zijn van de huidige rechten.
Het huidige ZimaOS maakt het koppelen van applicatieopslag eenvoudiger
Het huidige ZimaOS documenteert host- en containerpaden rechtstreeks in de applicatie-instellingen en raadt aan appgegevens op beheerde opslag op te slaan, zodat applicaties de systeemschijf niet vullen.
Gebruik het huidige model van ZimaOS voor applicatiepaden voor Docker-volumes in plaats van te vertrouwen op oude CasaOS-koppellocaties.
De oorspronkelijke gebruiker installeerde Syncthing opnieuw en bouwde de koppeling opnieuw op
Nadat de eerste pogingen verwarrend bleven, voerde de oorspronkelijke poster een nieuwe installatie van Syncthing uit, voegde de opslagschijven opnieuw toe en koppelde /mnt/Storage1 op de host naar /DATA in de container. Met deze schone hertest werden oude containerinstellingen uit de diagnose verwijderd.
Alleen hostrechten konden het verkeerde containerpad niet laten werken
De gebruiker kon via SSH verbinding maken met de opslagschijf en mappen aanmaken, maar Syncthing bleef falen toen het de opdracht kreeg om /mnt/Storage1/Documents intern. Dat negatieve resultaat is waardevol: het feit dat je als hostgebruiker kunt schrijven, betekent niet dat de container dezelfde naamruimte kan zien.
De zichtbaarheid binnen de container moet correct zijn voordat het aanpassen van rechten iets kan oplossen.
Het huidige ZimaOS geeft de voorkeur aan beheerde opslagpaden
De discussie gaat over een ZimaBlade die werd geleverd met opslagpaden in CasaOS-stijl. Het huidige ZimaOS werkt met ander beheerd opslaggedrag en een duidelijkere interface voor applicatievolumes. Gebruik op een huidige server het opslagpad dat via ZimaOS is geselecteerd in plaats van zomaar aan te nemen /mnt/Storage1 of /media/devmon zal bestaan.
Wijzig alleen de rechten die de app daadwerkelijk nodig heeft
Syncthing heeft doorgaans lees- en schrijftoegang nodig tot zijn synchronisatiemap. Als een gekoppelde map zichtbaar maar niet schrijfbaar is, controleer dan de eigendom en groepsrechten van die specifieke map. Vermijd het recursief wijzigen van de eigenaar van een volledige schijf voor meerdere doeleinden, tenzij rekening is gehouden met elke andere service die die schijf gebruikt.
Veelgestelde vragen over een externe Syncthing-harde schijf
Waarom maakte Syncthing het pad naar de externe schijf aan op de systeemschijf?
Het hostpad was niet het pad dat Syncthing in zijn container kon zien.
Welk pad werkte nadat de schijf aan /DATA was gekoppeld?
De oorspronkelijke gebruiker bevestigde /DATA/Documents werkte.
Was recursief wijzigen van de eigenaar de enige oplossing?
Nee. Het doorslaggevende inzicht was het verschil tussen het hostpad en het containerpad.
