This thread started as a question about disabling a read-only filesystem in ZimaOS, but that was not the real problem. After checking the stack, the original poster found that the Compose file used relative volume paths.
That distinction matters because changing host filesystem permissions or remounting system paths would have been the wrong fix for this case.
Check the Compose File Before Changing ZimaOS
When a container stack cannot create or write to a path, first identify what the Compose file is mounting into the container. A bind mount can reference a host path, while a named volume is managed by Docker. The current Docker Compose volume rules notes that relative host paths are resolved from the Compose project location.
For a self-hosted NAS, an explicit persistent path is often easier to reason about than an ambiguous relative path because you can verify that the source directory actually exists and is writable.
Why the Read-Only Assumption Was Misleading
A true read-only filesystem problem usually affects more than one Compose path and should be diagnosed from the actual mount state and system logs. In this thread, the user did not need to turn off a ZimaOS protection mechanism. They corrected their relative volume configuration instead.
What the Community Suggested
Before the root cause was known, a community reply suggested opening ZimaOS Developer Mode, using the web terminal as root, and manually creating the required directory. That can be useful when the intended host path genuinely does not exist, but it should follow the Compose-path check rather than replace it.
A Safer Troubleshooting Order
- Inspect every
volumes:entry in the Compose file. - Determine whether each source is a named volume, absolute host path, or relative path.
- Confirm the expected host directory exists.
- Confirm the container is not explicitly mounted with
:roorread_only: true. - Only investigate host filesystem mount state if the same write failure persists outside the container configuration.
Current Docker and Portainer Context
For current ZimaOS deployments, the Portainer hardware requirements gives the broader Portainer persistence and runtime context, while the first Docker app explains how ZimaOS applications map persistent data into containers. If a mount is genuinely read-only rather than merely misaddressed, the Docker bind mount fix separates a configured :ro mount from a host filesystem that has stopped accepting writes.
Docker's Docker bind mount rules confirms that bind mounts can use host source paths and that read-only behavior is explicitly controlled with readonly or ro. The official Portainer stack behavior defines a Portainer stack as a related set of services, which is why the Compose file should be inspected before changing the ZimaOS host itself.
Bottom Line
The reported Portainer stack error was not solved by disabling a read-only filesystem. The user corrected relative volume paths in docker-compose.yml. For similar ZimaOS container errors, validate the Compose mount definition before making host-level filesystem changes.
