Deze thread begon als een vraag over het uitschakelen van een alleen-lezenbestandssysteem in ZimaOS, maar dat was niet het echte probleem. Na controle van de stack ontdekte de oorspronkelijke poster dat het Compose-bestand relatieve volumepaden gebruikte.
Dat onderscheid is belangrijk, omdat het wijzigen van de machtigingen van het hostbestandssysteem of het opnieuw koppelen van systeempaden in dit geval de verkeerde oplossing zou zijn geweest.
Controleer het Compose-bestand voordat je ZimaOS wijzigt
Wanneer een containerstack geen pad kan aanmaken of erin kan schrijven, controleer je eerst wat het Compose-bestand in de container koppelt. Een bind mount kan verwijzen naar een pad op de host, terwijl een benoemd volume door Docker wordt beheerd. De actuele volumeregels van Docker Compose vermelden dat relatieve hostpaden worden opgelost vanaf de locatie van het Compose-project.
Voor een zelfgehoste NAS is een expliciet persistent pad vaak eenvoudiger te begrijpen dan een dubbelzinnig relatief pad, omdat je kunt controleren of de bronmap daadwerkelijk bestaat en beschrijfbaar is.
Waarom de aanname van alleen-lezen misleidend was
Een echt probleem met een alleen-lezenbestandssysteem heeft meestal gevolgen voor meer dan één Compose-pad en moet worden gediagnosticeerd aan de hand van de daadwerkelijke mountstatus en systeemlogboeken. In deze thread hoefde de gebruiker geen beveiligingsmechanisme van ZimaOS uit te schakelen. In plaats daarvan werd de configuratie van de relatieve volumes gecorrigeerd.
Wat de community voorstelde
Voordat de hoofdoorzaak bekend was, stelde een communitylid voor om de ontwikkelaarsmodus van ZimaOS te openen, de webterminal als root te gebruiken en de vereiste map handmatig aan te maken. Dat kan nuttig zijn wanneer het bedoelde hostpad inderdaad niet bestaat, maar dit moet volgen op de controle van het Compose-pad en die controle niet vervangen.
Een veiligere volgorde voor probleemoplossing
- Controleer elke
volumes:-vermelding in het Compose-bestand. - Bepaal of elke bron een benoemd volume, een absoluut hostpad of een relatief pad is.
- Controleer of de verwachte hostmap bestaat.
- Controleer of de container niet expliciet is gekoppeld met
:roofread_only: true. - Onderzoek de mountstatus van het hostbestandssysteem pas als dezelfde schrijffout buiten de containerconfiguratie blijft optreden.
De huidige Docker- en Portainer-context
Voor huidige ZimaOS-implementaties bieden de hardwarevereisten van Portainer de bredere context voor persistentie en runtime van Portainer, terwijl de eerste Docker-app uitlegt hoe ZimaOS-applicaties persistente gegevens aan containers koppelen. Als een mount daadwerkelijk alleen-lezen is en niet slechts naar het verkeerde pad verwijst, maakt de oplossing voor Docker-bind mounts onderscheid tussen een geconfigureerde :ro-mount en een hostbestandssysteem dat geen schrijfbewerkingen meer accepteert.
De regels voor Docker-bind mounts bevestigen dat bind mounts hostbronpaden kunnen gebruiken en dat alleen-lezen gedrag expliciet wordt ingesteld met readonly of ro. Het officiële stackgedrag van Portainer definieert een Portainer-stack als een samenhangende set services. Daarom moet het Compose-bestand worden gecontroleerd voordat je de ZimaOS-host zelf wijzigt.
Conclusie
De gemelde fout bij de Portainer-stack werd niet opgelost door een alleen-lezenbestandssysteem uit te schakelen. De gebruiker corrigeerde de relatieve volumepaden in docker-compose.yml. Controleer bij vergelijkbare containerfouten in ZimaOS eerst de mountdefinitie in Compose voordat je wijzigingen aanbrengt in het bestandssysteem op hostniveau.
