Use shared property for automounts

[aawdls]

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 for bind-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?

[gilesknap]

Good work Andy, how did you find out about this! I thought this was awaiting a bug fix.

[gilesknap]

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?

[aawdls]

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.

[gilesknap]

@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.

[aawdls]

Dev container works. I saw the initializeCommand to do the ls was still there so I have removed it, is that right?

[gilesknap]

Oh right yes that needed removing thanks!