podman: bind-propagation -- shared -- not working
Is this a BUG REPORT or FEATURE REQUEST?:
[//]: # Uncomment only one, leave it on its own line:
[//]: # kind bug
Description
Trying to use bind-propagation shared with podman does not work.
Steps to reproduce the issue:
1. podman run --privileged -it --rm -v /root/owntmp:/owntmp:shared fedora bash
2. [container] # mount -o bind /usr /owntmp/usr
3. [container] # ls /owntmp/usr
bin games include lib lib64 libexec local sbin share src tmp
4. [host] # ls /root/owntmp/usr
Describe the results you received:
An empty directory on the host.
Describe the results you expected:
A populated directory on the host.
ls /root/owntmp/usr should give the same output as a ls /owntmp/usr in the container.
Additional information you deem important (e.g. issue happens only occasionally):
Tested on RHEL-7.6, RHCOS-4.0
Output of podman version:
Version: 0.10.1.3
Go Version: go1.10.2
OS/Arch: linux/amd64
Output of podman info:
ost:
BuildahVersion: 1.5-dev
Conmon:
package: podman-0.10.1.3-1.gitdb08685.el7.x86_64
path: /usr/libexec/podman/conmon
version: 'conmon version 1.12.0-dev, commit: 0e7abf050824203d775a20c26ed14f716f7d1aa7-dirty'
Distribution:
distribution: '"rhcos"'
version: "4.0"
MemFree: 118853488640
MemTotal: 128844967936
OCIRuntime:
package: runc-1.0.0-52.dev.git70ca035.el7_5.x86_64
path: /usr/bin/runc
version: 'runc version spec: 1.0.0'
SwapFree: 0
SwapTotal: 0
arch: amd64
cpus: 16
hostname: ip-10-0-143-109
kernel: 3.10.0-957.el7.x86_64
os: linux
uptime: 29h 22m 13.1s (Approximately 1.21 days)
insecure registries:
registries: null
registries:
registries:
- registry.access.redhat.com
- docker.io
store:
ContainerStore:
number: 48
GraphDriverName: overlay
GraphOptions:
- overlay.override_kernel_check=true
GraphRoot: /var/lib/containers/storage
GraphStatus:
Backing Filesystem: xfs
Native Overlay Diff: "true"
Supports d_type: "true"
ImageStore:
number: 10
RunRoot: /var/run/containers/storage
Additional environment details (AWS, VirtualBox, physical, etc.):
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Comments: 19 (13 by maintainers)
Commits related to this issue
- set root propagation based on volume properties Set the root propagation based on the properties of volumes and default mounts. To remain compatibility, follow the semantics of Docker. If a volume ... — committed to vrothberg/libpod by vrothberg 6 years ago
- set root propagation based on volume properties Set the root propagation based on the properties of volumes and default mounts. To remain compatibility, follow the semantics of Docker. If a volume ... — committed to vrothberg/libpod by vrothberg 6 years ago
- set root propagation based on volume properties Set the root propagation based on the properties of volumes and default mounts. To remain compatibility, follow the semantics of Docker. If a volume ... — committed to vrothberg/libpod by vrothberg 6 years ago
- set root propagation based on volume properties Set the root propagation based on the properties of volumes and default mounts. To remain compatibility, follow the semantics of Docker. If a volume ... — committed to vrothberg/libpod by vrothberg 6 years ago
- set root propagation based on volume properties Set the root propagation based on the properties of volumes and default mounts. To remain compatibility, follow the semantics of Docker. If a volume ... — committed to vrothberg/libpod by vrothberg 6 years ago
- set root propagation based on volume properties Set the root propagation based on the properties of volumes and default mounts. To remain compatibility, follow the semantics of Docker. If a volume ... — committed to vrothberg/libpod by vrothberg 6 years ago
- set root propagation based on volume properties Set the root propagation based on the properties of volumes and default mounts. To remain compatibility, follow the semantics of Docker. If a volume ... — committed to vrothberg/libpod by vrothberg 6 years ago
- set root propagation based on volume properties Set the root propagation based on the properties of volumes and default mounts. To remain compatibility, follow the semantics of Docker. If a volume ... — committed to vrothberg/libpod by vrothberg 6 years ago
A word of advice unrelated to the actual bind propogation problem: If you want to mount /var/lib/containers into a container, we strongly recommend you also mount the host’s /var/run as well - if you don’t, c/storage and Podman can assume the system restarted and lose track of critical state (like what’s mounted).
Will investigate bind propogation.