Build-time bind mount not working on OSX

[mpanetta]

/kind bug

Description

Bind mounts do not work when running on OSX, have tried from OSX terminal and from within the podman virtual machine.
Have tried rootless and rootful machines - neither seem to work.

Steps to reproduce the issue:

cat Containerfile
FROM fedora
RUN touch /srv/foo.txt

podman build -f Containerfile -v /tmp:/srv
STEP 1/2: FROM fedora
STEP 2/2: RUN touch /srv/foo.txt
--> Using cache 636aff403de1a619ab3fd10e308d4e759232f9651a039e1a72dee88a207981e2
--> 636aff403de
636aff403de1a619ab3fd10e308d4e759232f9651a039e1a72dee88a207981e2

ls /tmp/foo.txt
ls: /tmp/foo.txt: No such file or directory

Describe the results you received:

The bind mount does not appear to be working (I do not see the file on my host file system as expected). I DO see the file being created on the COW filesystem in the container.

Describe the results you expected:

I expect the file to be created on my host.

Additional information you deem important (e.g. issue happens only occasionally):

Happens every time.

Output of podman version:

podman version 4.3.0

Output of podman info:

host:
  arch: arm64
  buildahVersion: 1.28.0
  cgroupControllers:
  - cpuset
  - cpu
  - io
  - memory
  - pids
  - misc
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon-2.1.5-1.fc37.aarch64
    path: /usr/bin/conmon
    version: 'conmon version 2.1.5, commit: '
  cpuUtilization:
    idlePercent: 93.6
    systemPercent: 3.1
    userPercent: 3.3
  cpus: 1
  distribution:
    distribution: fedora
    variant: coreos
    version: "37"
  eventLogger: journald
  hostname: localhost.localdomain
  idMappings:
    gidmap: null
    uidmap: null
  kernel: 6.0.9-300.fc37.aarch64
  linkmode: dynamic
  logDriver: journald
  memFree: 970612736
  memTotal: 2049789952
  networkBackend: netavark
  ociRuntime:
    name: crun
    package: crun-1.7-1.fc37.aarch64
    path: /usr/bin/crun
    version: |-
      crun version 1.7
      commit: 40d996ea8a827981895ce22886a9bac367f87264
      rundir: /run/crun
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +LIBKRUN +WASM:wasmedge +YAJL
  os: linux
  remoteSocket:
    exists: true
    path: /run/podman/podman.sock
  security:
    apparmorEnabled: false
    capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
    rootless: false
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: true
  serviceIsRemote: true
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.2.0-8.fc37.aarch64
    version: |-
      slirp4netns version 1.2.0
      commit: 656041d45cfca7a4176f6b7eed9e4fe6c11e8383
      libslirp: 4.7.0
      SLIRP_CONFIG_VERSION_MAX: 4
      libseccomp: 2.5.3
  swapFree: 0
  swapTotal: 0
  uptime: 0h 35m 9.00s
plugins:
  authorization: null
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  volume:
  - local
registries:
  search:
  - docker.io
store:
  configFile: /usr/share/containers/storage.conf
  containerStore:
    number: 2
    paused: 0
    running: 1
    stopped: 1
  graphDriverName: overlay
  graphOptions:
    overlay.mountopt: nodev,metacopy=on
  graphRoot: /var/lib/containers/storage
  graphRootAllocated: 106769133568
  graphRootUsed: 4187066368
  graphStatus:
    Backing Filesystem: xfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "true"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 18
  runRoot: /run/containers/storage
  volumePath: /var/lib/containers/storage/volumes
version:
  APIVersion: 4.3.1
  Built: 1668178831
  BuiltTime: Fri Nov 11 10:00:31 2022
  GitCommit: ""
  GoVersion: go1.19.2
  Os: linux
  OsArch: linux/arm64
  Version: 4.3.1

Package info (e.g. output of rpm -q podman or apt list podman or brew info podman):

From within the podman virtual machine

podman-4.3.1-1.fc37.aarch64

Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide?

Yes

Additional environment details (AWS, VirtualBox, physical, etc.):

OSX 13.0.1, Podman Desktop (not sure which version, just installed it from Podman.io 2 days ago).

[Luap99]

It works as designed at the moment. The podman machine VM shares predefined mounts with the host, they must be given at podman machine init time. By default only $HOME is mounted, if you want to mount something else you need to recreate the vm, see https://docs.podman.io/en/latest/markdown/podman-machine-init.1.html#volume-v-source-target-options

I think @ashley-cui has been started to work on dynamic mounting for machine VM but I am not sure what the state there is?

[ashley-cui]

Current state is the work is put on pause, as we need more research and design. It's definitely high priority for us though.

[mpanetta]

@Luap99 , @ashley-cui I am, in fact, mounting from my home directory (from $(HOME)/tmp). The above was an effort to simplify things to explain the issue. I am able to write to the shared volume from the container and see those changes after I build, but not during the build. Is there some other action I need to take to be able to actually write to the shared volume during the container build?

[Luap99]

see those changes after I build, but not during the build.

I don't understand what that means?

Looking at the man page it says podman build --volume is not supported with the remote client.

[mpanetta]

see those changes after I build, but not during the build.

I don't understand what that means?

Looking at the man page it says podman build --volume is not supported with the remote client.

When I am building the container, I write files into the shared volume. Those changes do NOT show up on the host. After the container is built, I can make changes to the shared volume while running the container and I see those changes on my host.

As in the original example, if during a container build, I touch a file in the shared volume, I do not see that file on my host. After the build, if I look at the shared volume in the container, I do not see the file either.

But, after building the container, I can , e.g. podman exec -it <container> bash, go to the shared volume, make a change, e.g. touch foo.txt, and that change will persist, be visible in the volume on the host as well, etc. as expected. So I know the volume I am sharing is correct, but I cannot seem to write to that volume while building the container.

Does that help?

[rhatdan]

podman build tar's up the local content and the install happens on the server side.
podman build -v /SOURCE:/DEST

Is not supported on MAC and Windows boxes or any remote client.

[Luap99]

podman build --volume should be supported on the remote client as well. It works for podman run. Of course the volume path is always on the server but that is ok in many cases such as this one where the machine already mounts the remote path.