A custom Docker app may require more than a simple host-to-container path. In this January 2026 ZimaOS discussion, an SSHFS-based container needed mount propagation using a :shared option. Entering that option in the ZimaOS custom-app volume field caused the container to fail, while the same mount without the option did not provide the host-side behavior the application required.
The important distinction from the thread is between the ZimaOS WebUI editor and the underlying Docker stack. Community testing showed that Docker volume and bind-mount options could work through Docker Compose or CLI workflows, while the WebUI did not correctly parse or preserve options such as :shared, :ro, and :readonly.
The Limitation Was in the WebUI, Not Standard Docker
The original poster initially asked whether ZimaOS itself lacked support for advanced volume flags. After testing, the discussion converged on a narrower conclusion: the Docker engine could use the options, but the ZimaOS custom-app form did not expose or preserve them correctly.
A related December 2025 thread reached the same conclusion for read-only mounts. A ZimaOS team member, Zima-Jerry, replied that future WebGUI versions would include more editor options and that the design work was in progress.
That historical status should not be converted into a promise or release date. On August 24, 2026, another community member reported that the read-only UI issue was still unresolved and asked for an ETA; the thread did not contain a later team response.
Why :shared Matters for Some Containers
The source case involved SSHFS. The container was being used to mount a remote filesystem, and the user needed the resulting mount to propagate beyond the container namespace. For this type of workflow, simply mapping a host path into the container is not equivalent to using the required mount-propagation option.
That is why advice based only on ordinary persistent app-data volumes did not solve the reported SSHFS use case. Different containers can require different mount semantics.
For the current Docker behavior and syntax, see the Docker bind-mount and propagation documentation.
The Same UI Problem Affected :ro and :readonly
The linked December 2025 discussion documented a similar issue with read-only mounts. A community responder reported that the ZimaOS UI could rewrite the mount and drop the :ro suffix when the volume configuration was edited or reopened.
This matters for more than convenience. A mount intended to be read-only should not silently become writable. If read-only access is part of your security or data-protection model, verify the actual container mount configuration rather than relying only on what was typed into the historical WebUI.
Docker Compose Was the Practical Workaround
The original poster confirmed that a standard Docker Compose definition could express the required mount options even when the ZimaOS graphical form could not. The workaround in the thread was therefore to manage the advanced mount through Compose instead of relying on the volume textbox.
Current ZimaOS documentation, updated in August 2026, still describes Docker Compose as the advanced path for power users and states that standard container runtime configuration belongs in Docker Compose. See the current ZimaOS feature documentation and the current ZimaOS Docker Compose reference.
Those current documents confirm Compose support, but they do not document a dedicated WebUI control for every Docker mount option. If a mount flag is essential, validate the resulting Compose/runtime configuration instead of assuming the GUI preserved it.
What This Thread Does Not Prove
- It does not mean ordinary ZimaOS app-data volumes require
:shared. - It does not mean Docker on ZimaOS lacks advanced mount support.
- It does not establish that every current WebUI version still behaves exactly like the January 2026 build.
- It does not provide an official delivery date for additional volume-option controls.
ZimaOS Volume Options FAQ
Can the ZimaOS custom-app WebUI use :shared?
In the January 2026 source thread, the WebUI did not correctly handle the option. The required behavior worked through Docker Compose instead.
Does ZimaOS Docker support :ro and :readonly?
The discussion distinguishes Docker support from the historical UI limitation. Docker supports read-only mount options, while the ZimaOS WebUI discussed in these threads did not reliably preserve them.
Was the WebUI limitation officially acknowledged?
Yes. In the related December 2025 thread, Zima-Jerry said that more editor options were being designed for future WebGUIs. No release date was given.
Is the issue fixed now?
The source material does not establish a confirmed fix. A community follow-up on August 24, 2026 still described the read-only UI problem as unresolved, while current ZimaOS documentation continues to recommend Docker Compose for advanced configuration.
