Solução da comunidade

Use Read-Only Docker Volumes in ZimaOS Custom Apps

A ZimaOS user found that the WebUI did not preserve Docker :ro or readonly mount options. Community replies clarified that standard Docker on ZimaOS supports the flags through Compose/CLI, while IceWhale said richer WebGUI mount options were being designed.

Docker on ZimaOS supports read-only bind mounts, but the ZimaOS Custom App WebUI discussed in this community thread does not reliably preserve options such as :ro or :readonly when editing a volume mapping. That is a WebUI limitation, not a limitation of Docker itself.

The community workaround is to export or write the Compose YAML manually and create the application with Docker Compose or the CLI. IceWhale acknowledged in December 2025 that future WebGUIs were being designed with more editor options. A later reply on August 24, 2026 still described the read-only UI behavior as unresolved, so current users should verify the actual container mount rather than assuming the UI preserved the flag.

Docker Supports Read-Only Bind Mounts

Docker's current bind mount documentation supports both ro and readonly options.

With the short -v syntax:

docker run -v /host/path:/container/path:ro IMAGE

Docker also accepts readonly as an option in its documented bind-mount syntax. With --mount:

docker run --mount type=bind,src=/host/path,dst=/container/path,readonly IMAGE

A read-only mount prevents the container from writing through that mount while still allowing it to read the host files.

What the ZimaOS WebUI Was Doing

The original user reported that when a volume was edited in the WebUI, the interface did not recognize the trailing :ro flag. A community reply described the behavior more specifically: the UI would rewrite the mount and silently drop the read-only option when the application was saved or reopened.

That distinction matters. The underlying Docker engine can create the correct read-only mount, but the GUI's volume field may not represent all Docker mount options.

What IceWhale Said About the Limitation

On December 26, 2025, Zima-Jerry replied that future WebGUIs would have more editor options and that the interface was still being designed. The thread later received an August 24, 2026 reply calling the missing read-only feedback a security concern and asking for an ETA.

The source thread does not contain a later IceWhale confirmation that the UI limitation has been fixed. For that reason, do not assume a current WebUI field is safe for :ro until you verify the actual container mount.

Use Docker Compose for Read-Only Mounts

The community workaround was to export the app's Compose YAML from ZimaOS, edit the mount, and recreate the container with standard Docker Compose.

Docker Compose supports an access mode as the third field in short volume syntax:

services:
  app:
    image: your/image:latest
    volumes:
      - /DATA/example:/data:ro

Docker's current Compose file reference documents ro as the read-only access mode for a mounted volume or bind path.

A Practical ZimaOS Workflow

  1. Open the custom application's settings.
  2. Export the Compose YAML if your current ZimaOS build provides that option.
  3. Save a backup copy before editing.
  4. Add :ro to only the host paths that the container should not modify.
  5. Validate the YAML.
  6. Use an authorized terminal to run Docker Compose.
  7. Verify the resulting mount before trusting it with sensitive files.

A normal Compose command is:

docker compose up -d

Run it from the directory containing the Compose file, and understand that a manually managed Compose project may no longer behave exactly like an app managed entirely through the ZimaOS UI.

Verify That the Mount Is Actually Read-Only

Do not trust only the YAML or the WebUI label. Inspect the running container:

docker inspect CONTAINER_NAME

In the Mounts section, Docker shows whether the mount is writable. A correctly read-only bind mount should report:

"RW": false

Docker's own documentation uses this inspection method to verify read-only mounts.

Test the Access Boundary Carefully

You can also test from inside a disposable or non-critical container by trying to create a file in the mounted path. A correctly configured read-only mount should reject the write.

Do not test by overwriting an important file. Use a harmless temporary filename and remove any test artifacts from the host if the write unexpectedly succeeds.

:ro and :readonly Are Docker Options, but Syntax Matters

The original title mentions both :ro and :readonly. Docker's current bind-mount documentation accepts both names in applicable mount-option contexts. The most widely used Compose short syntax is:

/host/path:/container/path:ro

For long or --mount syntax, readonly is also documented. Match the option to the Docker syntax you are actually using rather than pasting a suffix into a ZimaOS field that only expects a container path.

A Read-Only Mount Is Different from a Read-Only Container Filesystem

Docker Compose also has a service-level read_only option. That makes the container's root filesystem read-only. It is not the same as marking one bind mount read-only.

For example:

services:
  app:
    image: your/image:latest
    read_only: true

Only use that when the application is designed to run with a read-only root filesystem and its required writable paths are mounted separately.

Avoid Re-Saving the Volume in a UI That Drops the Flag

A community reply suggested treating the ZimaOS WebUI as effectively write-only for volume settings once a read-only mount has been created manually. The concern is that reopening and saving the app through a GUI that does not understand the option can rewrite the mount without :ro.

Before making later UI changes, export the current Compose configuration and verify the mount afterward.

Why This Matters for Security

Read-only mounts are often used to give an application access to configuration, media, certificates, backups, or source data without giving it permission to modify those files.

If a UI silently changes a mount from read-only to read-write, the container receives more host filesystem access than the administrator intended. That is why verification with docker inspect is important until the UI itself reliably represents the option.

ZimaOS Read-Only Docker Mount Checklist

  1. Confirm the application really needs only read access.
  2. Do not assume the ZimaOS WebUI preserves :ro.
  3. Export or write a Compose file.
  4. Use /host:/container:ro for the intended mount.
  5. Start the project with standard Docker Compose.
  6. Verify the mount with docker inspect.
  7. Confirm RW is false.
  8. Be careful when reopening or resaving the application in the WebUI.
  9. Keep a copy of the working Compose YAML for recovery.

ZimaOS Docker Read-Only Mount FAQ

Does ZimaOS Docker support :ro?

Yes at the Docker engine/Compose level. The source thread identifies the limitation as the ZimaOS WebUI's handling of mount options.

Has the WebUI issue been confirmed fixed?

Not in this source thread. An August 24, 2026 reply still described the read-only UI behavior as unresolved.

What is the best current workaround?

Export or create a Compose YAML file, add the read-only mount there, run docker compose up -d, and verify the running container with docker inspect.

Is service read_only the same as a :ro volume?

No. Service-level read_only: true affects the container root filesystem. A :ro volume affects only that specific mount.

Why is silently losing :ro a security issue?

Because the container may gain write access to host files that the administrator intended to expose only for reading.