Closed aawdls closed 1 year ago
Good work Andy, how did you find out about this! I thought this was awaiting a bug fix.
I don't understand the question about making mounts visible on the host as I don't see much detail in man podman-run. Where did you get details on this?
I got the idea from Google. The option is explained in man-podman-run as:
Mounts propagation
By default bind mounted volumes are private. That means any mounts done
inside container will not be visible on host and vice versa. One can
change this behavior by specifying a volume mount propagation property.
Making a volume shared mounts done under that volume inside container
will be visible on host and vice versa. Making a volume slave enables
only one way mount propagation and that is mounts done on host under
that volume will be visible inside container but not the other way
around. [1] ⟨#Footnote1⟩
To control mount propagation property of a volume one can use the
[r]shared, [r]slave, [r]private or the [r]unbindable propagation flag.
For mount propagation to work the source mount point (the mount point
where source dir is mounted on) has to have the right propagation prop‐
erties. For shared volumes, the source mount point has to be shared.
And for slave volumes, the source mount point has to be either shared
or slave. [1] ⟨#Footnote1⟩
We didn't understand what the reference to the propagation of the source mount point means so read man mount
:
Shared subtree operations
Since Linux 2.6.15 it is possible to mark a mount and its submounts as
shared, private, slave or unbindable. A shared mount provides the
ability to create mirrors of that mount such that mounts and unmounts
within any of the mirrors propagate to the other mirror. A slave mount
receives propagation from its master, but not vice versa. A private
mount carries no propagation abilities. An unbindable mount is a pri‐
vate mount which cannot be cloned through a bind operation. The
detailed semantics are documented in Documentation/filesystems/shared‐
subtree.txt file in the kernel source tree.
I take this to mean that with private (the default) an automount that appears on the host after the container started won't be visible to the container, whereas with shared (or slave) it will be. But I admit this is a reverse-engineering of a convenient explanation without fully understanding the mechanism.
@aawdls this looks all good. It works for me and I have added the same options to the devcontainer.json.
Please can you try opening the devcontainer in vscode and it works for you then go ahead and merge.
Dev container works. I saw the initializeCommand to do the ls
was still there so I have removed it, is that right?
Oh right yes that needed removing thanks!
I found that the existing method wasn't working for me - I kept getting the "too many levels of symbolic links" error from the automounted directories. This is a proposal for an alternative method that seems to work for me.
See
man podman-run
, search forbind-propagation
, for what it is doing. I think it is okay to make the container mounts visible on the host since they are alaready visible where mounted on the host. Is this a correct assumption?