podman run --mount "ro=false" results in read-only mount

[caffeinejolt]

podman-0.12.1.2-2.git9551f6b.el7.centos.x86_64
centos-release-7-6.1810.2.el7.centos.x86_64

If I do not specify any "ro" value - it does default to writable. However, the docs indicate that "ro=false" is the default - but if I specify the default, I end up with a read-only mount.

On a side-note, the docs don't really state the difference between --mount and --volume - if you read man podman-run, the reader is left to assume they are two ways of specifying a bind mount - is there any functional difference? Or is it all the same bind mount in the end?

[mheon]

On mount vs volume - they are two syntaxes to accomplish the same goal. There are some bugs in mount we're looking to resolve, but once those are fixed they will be functionally identical.

…

On Fri, Apr 19, 2019, 18:16 caffeinejolt ***@***.***> wrote: podman-0.12.1.2-2.git9551f6b.el7.centos.x86_64 centos-release-7-6.1810.2.el7.centos.x86_64 If I do not specify any "ro" value - it does default to writable. However, the docs indicate that "ro=false" is the default - but if I specify the default, I end up with a read-only mount. On a side-note, the docs don't really state the difference between --mount and --volume - if you read man podman-run, the reader is left to assume they are two ways of specifying a bind mount - is there any functional difference? Or is it all the same bind mount in the end? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2980>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AB3AOCBC7URLX4BJQVMT4C3PRJADVANCNFSM4HHIHE5A> .

[mheon]

There's a very large rework to the --mount flag going in at #2959 - a little too large for me to be comfortable adding more to it - but once it lands I'll get a fix for this in.

The issue is that we're not checking if some mount flags (ro, rw, probably more) accept an argument, so if we see them we unconditionally toggle read-only on.

[caffeinejolt]

Cool - I would rate this as a pretty low priority fix anyways since there are easy workarounds.

[rhatdan]

@caffeinejolt @mheon is this still a bug?

[mheon]

Yes. I'll work on this one tomorrow.