Cannot mount local folder with HyperV

[jeffmaury]

Issue Description

If I try to mount a local folder in a container with HyperV machine, it is rejected:

C:\Users\Jeff>podman run -it --rm -v %CD%:/jeff busybox
Error: statfs /mnt/c/Users/Jeff: no such file or directory

Steps to reproduce the issue

Steps to reproduce the issue

1. Create an HyperV machine
2. Run podman run -it -rm -v %CD%:/jeff busybox

Describe the results you received

Describe the results you received

Describe the results you expected

Error is raised

podman info output

host:
  arch: amd64
  buildahVersion: 1.32.0
  cgroupControllers:
  - cpu
  - io
  - memory
  - pids
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon-2.1.8-2.fc39.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.1.8, commit: '
  cpuUtilization:
    idlePercent: 97.94
    systemPercent: 1.23
    userPercent: 0.83
  cpus: 3
  databaseBackend: boltdb
  distribution:
    distribution: fedora
    variant: coreos
    version: "39"
  eventLogger: journald
  freeLocks: 2048
  hostname: localhost.localdomain
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 1000000
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 1000000
  kernel: 6.6.3-200.fc39.x86_64
  linkmode: dynamic
  logDriver: journald
  memFree: 208326656
  memTotal: 730513408
  networkBackend: netavark
  networkBackendInfo:
    backend: netavark
    dns:
      package: aardvark-dns-1.8.0-1.fc39.x86_64
      path: /usr/libexec/podman/aardvark-dns
      version: aardvark-dns 1.8.0
    package: netavark-1.8.0-2.fc39.x86_64
    path: /usr/libexec/podman/netavark
    version: netavark 1.8.0
  ociRuntime:
    name: crun
    package: crun-1.12-1.fc39.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 1.12
      commit: ce429cb2e277d001c2179df1ac66a470f00802ae
      rundir: /run/user/1000/crun
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +LIBKRUN +WASM:wasmedge +YAJL
  os: linux
  pasta:
    executable: /usr/bin/pasta
    package: passt-0^20231119.g4f1709d-1.fc39.x86_64
    version: |
      pasta 0^20231119.g4f1709d-1.fc39.x86_64
      Copyright Red Hat
      GNU General Public License, version 2 or later
        <https://www.gnu.org/licenses/old-licenses/gpl-2.0.html>
      This is free software: you are free to change and redistribute it.
      There is NO WARRANTY, to the extent permitted by law.
  remoteSocket:
    exists: true
    path: /run/user/1000/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: true
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: true
  serviceIsRemote: true
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.2.2-1.fc39.x86_64
    version: |-
      slirp4netns version 1.2.2
      commit: 0ee2d87523e906518d34a6b423271e4826f71faf
      libslirp: 4.7.0
      SLIRP_CONFIG_VERSION_MAX: 4
      libseccomp: 2.5.3
  swapFree: 0
  swapTotal: 0
  uptime: 0h 7m 21.00s
  variant: ""
plugins:
  authorization: null
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  - ipvlan
  volume:
  - local
registries:
  search:
  - docker.io
store:
  configFile: /var/home/core/.config/containers/storage.conf
  containerStore:
    number: 0
    paused: 0
    running: 0
    stopped: 0
  graphDriverName: overlay
  graphOptions: {}
  graphRoot: /var/home/core/.local/share/containers/storage
  graphRootAllocated: 106769133568
  graphRootUsed: 2369712128
  graphStatus:
    Backing Filesystem: xfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
    Supports shifting: "false"
    Supports volatile: "true"
    Using metacopy: "false"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 1
  runRoot: /run/user/1000/containers
  transientStore: false
  volumePath: /var/home/core/.local/share/containers/storage/volumes
version:
  APIVersion: 4.7.2
  Built: 1698762721
  BuiltTime: Tue Oct 31 14:32:01 2023
  GitCommit: ""
  GoVersion: go1.21.1
  Os: linux
  OsArch: linux/amd64
  Version: 4.7.2

Podman in a container

No

Privileged Or Rootless

None

Upstream Latest Release

Yes

Additional environment details

Additional environment details

Additional information

Additional information like issue happens only occasionally or issue happens with a particular architecture or on a particular setting

[rhatdan]

Could this be an SELinux issue?

Add :Z to volume mount.

[jeffmaury]

Closing as I can not reproduce

[jeffmaury]

Reopening as I face it again and adding :Z does not help

[rhatdan]

Is there a directory /mnt/c/Users/Jeff in the VM?

@n1hility @ashley-cui @baude is this where we are mounting the default users homedir?

[jeffmaury]

Is there a directory /mnt/c/Users/Jeff in the VM?

@n1hility @ashley-cui @baude is this where we are mounting the default users homedir?

the /mnt folder exists but it is empty

[rhatdan]

What happens on a Mac is we automatically mount the home directory into the VM, so I would assume something similar is being attempted or should be attempted on Windows with HyperV.

In containers.conf look at [Machine] table to see if there is a volumes entry like:

   volumes=["$HOME:$HOME"]

[jeffmaury]

What happens on a Mac is we automatically mount the home directory into the VM, so I would assume something similar is being attempted or should be attempted on Windows with HyperV.

In containers.conf look at [Machine] table to see if there is a volumes entry like:

   volumes=["$HOME:$HOME"]

I don't see such an entry in containers.conf

[rhatdan]

Might be an oversight in our HyperV support. @ashley-cui @baude @n1hility Should this be setup for Windows?

[rhatdan]

@jeffmaury you could try to set this in the config and stop and start the machine. Might need to recreate it to see if the volume shows up. I don't do Windows, so I am not sure what is and is not supported.

Obviously the core developers might not be responsive since Red Hat is closed for winter break.

[jeffmaury]

@jeffmaury you could try to set this in the config and stop and start the machine. Might need to recreate it to see if the volume shows up. I don't do Windows, so I am not sure what is and is not supported.

Obviously the core developers might not be responsive since Red Hat is closed for winter break.

If I had the volumes in the machine section, then I have this:

$ podman machine init test3
Extracting compressed file: test3_fedora-coreos-39.20231204.2.1-hyperv.x86_64.vhdx: done
Error: volume options are not presently supported on Hyper-V

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[KirilMihaylov]

Hello,

I'm sorry to barge in like this. I just wanted to ask whether this issue is being worked on, or if not, whether it is planned to be worked on. That feature would be a game changing experience for Windows users, I am sure of it.

It was mentioned that Mac also supported mounting local directories as volumes on a VM, so I am just wondering what can be done in the case of Hyper-V.

Thank you in advance!

[rhatdan]

Have you tried out podman 5.0 yet? If this does not work, the best way to get a feature in is to open a PR with the feature.

[KirilMihaylov]

I've been waiting for the official release but will try fiddling with the release candidates.

On the side, I get that if you want something, you should do it yourself, yet if it were Youki that caused me problems, I would've tried opening a PR, but sadly I am not proficient when it comes to Golang, or experienced at all for that matter.
I hope you can forgive my ignorance on the topic and have a good rest of your day/evening.

[rhatdan]

@ashley-cui Is this fixed in 5.0?

[KirilMihaylov]

TL;DR

It worked on 5.0, but needs more love to become more straight forward.

Long version

To update on the issue, on 5.0.0-rc6 it does work when my %UserProfile%\AppData\Roaming\containers\containers.conf is as follows:

[containers]
[engine]
[machine]
provider = "hyperv"
volumes = ["\\\\localhost\\c$\\:/mnt/c"]
[network]
[secrets]
[configmaps]
[farms]

The problems now are that podman machine start requires to be ran with escalated privileges AND it also spawns, in a non-obvious way, the filesystem sharing server as a background task of the terminal from which podman machine start was ran.

My current best-effort solution was to create a scheduled task which runs at system start-up as the "Administrators" group and Run with highest privileges marked as on.

As you can see, I also tried passing the --quiet flag, but that doesn't help with it opening a new terminal window just for that process when ran manually. I'm assuming that on reboot, when it's ran outside of my user session, it wouldn't show anywhere so that shouldn't be such a problem.

[jeffmaury]

For me it's is still broken on Windows as my home folder is mounted inside the VM as /Users/%USERNAME%

but when running podman run -d -v %CD%:/jeff nginx I am getting:

Error: statfs /mnt/c/Users/Jeff/apps/podman/next: no such file or directory

so it seems it is still trying to use the WSL mappings

[KirilMihaylov]

In that case, you would probably want to still map it with the full path, \\localhost\c$\Users\Jeff:/mnt/c/Users/Jeff. Perhaps \\localhost\c$\$Home:/mnt/c/$Home might also work if Podman does find and replace and not just basic equality check.

Also, if the problem persists, maybe try recreating the VM (or create another one and set it as default), as it produces JSON file configurations which, I found out by observations, are then used by the gvproxy/Plan 9 Protocol server. I am not sure whether Podman does update them on changes in containers.conf.

I hope that helps.

[jeffmaury]

In that case, you would probably want to still map it with the full path, \\localhost\c$\Users\Jeff:/mnt/c/Users/Jeff. Perhaps \\localhost\c$\$Home:/mnt/c/$Home might also work if Podman does find and replace and not just basic equality check.

Also, if the problem persists, maybe try recreating the VM (or create another one and set it as default), as it produces JSON file configurations which, I found out by observations, are then used by the gvproxy/Plan 9 Protocol server. I am not sure whether Podman does update them on changes in containers.conf.

I hope that helps.

Yes but as there are defaults provided, checking if they are correct as it's not required for WSL

[Luap99]

I think the issue the special path remap logic for windows paths that was added for WSL by @n1hility in #13908

That logic of course does not really apply to hyperV, or we could change the hyperV code to also always mount at /mnt//... to mimic WSL.

[n1hility]

@Luap99 IMO easiest / simplest is to just mirror the WSL convention, it's a good layout that avoids collisions, and you solve problems with the remote client code having to figure out which backend it's talking to.

[jtognazzi]

I'm using podman 5.0.3 on windows, and wanting to check if mounting local windows folder was supported with the hyperv provider.
So, if I read correctly, it is not yet supported.
But @KirilMihaylov wrote that he made it worked, so I'm a bit lost.
I tried what @KirilMihaylov mentioned and used his version of the containers.conf,
Inside the VM, I have this when executing the mount command:
$ mount

9p on /var/mnt/c type 9p (rw,relatime,access=client,trans=fd,rfd=3,wfd=3)

But the /var/mnt/c folder is not readable...

Update:
I changed the volumes line to point to a subfolder like this
volumes = ["\\\\localhost\\c$\\toto\\:/mnt/c/toto"]

and now the /var/mnt/c/toto is mounted and readable.

[l0rd]

I have opened a PR to address this problem (containers/common#2100). I have followed @n1hility suggestion so that, by default, Hyper-V machines volume mount is consistent with the WSL convention (e.g. C:\ get mounted under /mnt/c).

Machine e2e volume test work on Hyper-V with this fix and I have opened a separate PR to re-enable it #23401.

[l0rd]

Closing as that's fixed in main branch and the e2e CI test has been re-enabled.

[jeffmaury]

Reopening as I am facing the problem with 5.2.3

[l0rd]

@jeffmaury the fix is not included in 5.2.3, it will be in 5.3.0. In general Podman patch releases contain only the commits that are backported to the specific version branch (in this case v5.2). There was no particular request to backport the fix for this issue to 5.2.3 so it hasn't been included.