Closed jeffmaury closed 1 week ago
Could this be an SELinux issue?
Add :Z to volume mount.
Closing as I can not reproduce
Reopening as I face it again and adding :Z does not help
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?
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
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"]
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
Might be an oversight in our HyperV support. @ashley-cui @baude @n1hility Should this be setup for Windows?
@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 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
A friendly reminder that this issue had no activity for 30 days.
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!
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.
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.
@ashley-cui Is this fixed in 5.0?
It worked on 5.0, but needs more love to become more straight forward.
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.
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
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.
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
I think the issue the special path remap logic for windows paths that was added for WSL by @n1hility in https://github.com/containers/podman/pull/13908
That logic of course does not really apply to hyperV, or we could change the hyperV code to also always mount at /mnt/
@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.
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.
I have opened a PR to address this problem (https://github.com/containers/common/pull/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.
Closing as that's fixed in main branch and the e2e CI test has been re-enabled.
Issue Description
If I try to mount a local folder in a container with HyperV machine, it is rejected:
Steps to reproduce the issue
Steps to reproduce the issue
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
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