I’m attempting to install a container that does not exist in the app store, including the extra repositories. This container requires a “:shared” flag / option for a volume designation:
-v <mnt_path>:/mnt:shared
I’ve tried adding the flag in the gui, directly in the textbox, but this just crashes the container. Adding /mnt without the flag / option works. However the files are only accessible from within the container, defeating the purpose. Am I missing something or is this feature not implemented yet?
Thanks!
Edit: Just saw this post and I think I have the answer: Support for docker volume ":ro" or ":readonly" usage like decribed in docker docs
If this feature isn’t available then I can’t use ZimaOS unfortunately.
Actually, I don’t think the app needs a :shared flag, but the host side, should just be a shared path? This document on the zima site gives some volume path information. https://www.zimaspace.com/docs/zimaos/How-to-understand-Docker-App’s-paths-On-ZimaOS
I’m not sure what you’re trying to say, and the link you provided is broken. I know how volume flags work. The docker image is SSHFS and this is the mount point. If the shared flag is not supported or not present, then only the container can see the files in the mount. The shared flag let’s the host OS see the files as well.
Not to mention all the other flags.
These flag are essential for using many many containers. I can work around this by using docker compose, but these need to be exposed through the GUI or it defeats the purpose.
No, that isn’t true in zima volume mount cases. If you have a host accessible file location/ you map it to a volume inside the container, then both the container and the host can see and access those files, I do that all the time, without having to use any :shared. It’s volumes not bind mounts. All I know is I have full access to every docker that has a volume mapped to an inside mount like that.
You’re not missing anything, your conclusion is correct.
ZimaOS currently does not support Docker volume options like :shared, :ro, or :readonly when installing custom apps through the UI. Only basic bind mounts (/path:/container) are accepted. Adding mount flags causes the container to fail, which is why it crashes.
This is a platform limitation, not a configuration error. ZimaOS uses a restricted Docker implementation and does not expose mount propagation or volume flags, even if they’re valid in standard Docker.
So if a container requires :shared, it unfortunately won’t work on ZimaOS at this time. There’s no workaround via the UI or Portainer.
Hope that helps clarify things
I have no idea what’s going on here but both of you are misinformed or completely misunderstanding.
I can’t understand anything that SirWill is attempting to communicate. It’s barely English and they don’t seem to understand the topic or context at all. I really wish he’d stop replying honestly. They’re just confused and confusing the topic. The volume mapping works differently for different images. As stated with SSHFS, a container used to map remote file locations through SSH will only mount as visible from within the container. Without the shared flag this SSHFS mount is not visible by the host operating system. You can’t just say “no that’s not how it works” when that’s literally exactly how it works. That’s literally what the shared flag does by design.
And as I’ve already posted; this is not a limitation of ZimaOS at all. Just the GUI. You can use standard docker compose YAML files from the command line / ssh. I’m literally doing it right now. ZimaOS uses a standard docker install. You just make a compose file and run “docker compose up”. It fully supports the volume flags.
I’m not going to respond here anymore. The GUI needs updated. That’s all. Nothing more. The work around is fine. Yeesh. Why even have a form if everybody who responds is going to give false information?
Tl;dr: ZimOS GUI does not consider the volume flags. However the underlying docker does through compose. That’s it, done, finished. It’s just in development as stated in the linked thread in the first post.
Let’s close this properly, with facts and context.
This exact behaviour was already explained in this forum on Dec 24, including by me, and later confirmed by Jerry from the ZimaOS team:
- Docker on ZimaOS is standard Docker
- Volume flags like
:shared, :ro, and :readonly work correctly via Docker Compose / CLI
- The limitation is only in the ZimaOS WebUI, which does not parse or preserve volume flags and rewrites mounts
- This is acknowledged by the team and is in development
That position hasn’t changed.
So no, this wasn’t a misunderstanding of Docker, SSHFS, or mount propagation — it was a matter of clarifying GUI vs Docker scope, which is now explicitly aligned.
Your TL;DR is accurate and matches what’s already been documented here. The workaround is valid, and the feature request explains the gap.
This thread should now be clear and useful for anyone else running into the same issue.
1 Like