[Request]: Document --volume's three-part form ("host:guest:opts") and clarify support of other mount options, e.g. nosuid.

[VoidingWarranties]

Feature or enhancement request details

The parser for the --volume flag accepts an undocumented form: hostpath:guestpath:options. Is this form part of the stable and supported CLI?

As far as I can tell these options are passed all the way through to the Containerization package's Sources/ContainerizationOS/Mount/Mount.swift, where they're mapped onto the kernel's MS_* flags. However, for virtiofs bind mounts the options are only applied if ro / MS_RDONLY is specified. If this form is part of the stable/supported CLI, is it a bug or intended behavior that other mount options, such as nosuid, are silently dropped without the ro option for virtiofs bind mounts?

Code of Conduct

• I agree to follow this project's Code of Conduct

[magicashu]

Hi! I'd like to work on the documentation side of this issue.

I dug into the code to confirm the behavior described here:

The three-part form is real but undocumented. Parser.volume (Sources/Services/ContainerAPIService/Client/Parser.swift#L510-L562) accepts case 2, 3: — the third component is split on commas into mount options, for both named volumes and host-path bind mounts. Neither the --volume help text nor docs/how-to.md / docs/command-reference.md mention it.

The silent drop of non-ro options is reproducible from the code path. Options flow through intact (RuntimeService → Mount.share → AttachedFilesystem → guest bind mount as ["bind"] + options in LinuxContainer.swift). The drop happens in ContainerizationOS/Mount/Mount.swift: the initial mount(2) call carries MS_BIND, and the kernel ignores flags like MS_NOSUID on a plain bind. The follow-up remount that would apply them is gated on both MS_BIND and MS_RDONLY being set — so nosuid alone is silently lost, while ro,nosuid applies both.

Two questions for the maintainers:

1. Is the three-part form considered stable/supported CLI surface? If so, I have a docs PR ready (help text + how-to.md + command-reference.md, including a note about the current ro interaction) and will open it shortly.
2. Should the remount in Mount.swift fire whenever extra flags are present rather than only with ro (or alternatively warn when options are dropped)? Happy to take that up in apple/containerization as a separate PR if there's agreement on the intended behavior.