Support native volume mounts in interaction with podman desktop wsl integration

[schlichtanders]

Feature request description

This relates to https://github.com/containers/podman/issues/8016 in that the solution there to mount the whole user directory within podman machine init -v $USER:$USER does not work on podman desktop with wsl2 setup when using pod man from another wsl (e.g. Ubuntu), as the podman machine is run in a completely different container.

This was already reported at the respective discussion page https://github.com/containers/podman/discussions/13537?sort=new#discussioncomment-6344096, but never raised any significant attention so far.

For podman desktop to be a functional alternative to docker desktop for windows, such a native volume mount support is key.

Suggest potential solution

Some form of automatic tunnel setup between the containers would be ideal. If it could happen generically for podman-remote, the better, but if only a windows wsl.exe specific solution is feasible, that would be enough for this issue.

Have you considered any alternatives?

I couldn't find any alternative. Docker Desktop for Windows, of course, but that is licensed and not open source.

Additional context

Add any other context or screenshots about the feature request here.

[arixmkii]

WSL2 should by default mount all your drives into VM. With default config your user home will be located in /mnt/c/Users/<username>

This is output from newly created machine (everything default)

[~]$ ls -l /mnt/c/Users/
total 0
lrwxrwxrwx 1 user user   18 Apr  1  2024 'All Users' -> /mnt/c/ProgramData
drwxrwxrwx 1 user user 4096 Jan 21 23:32  User
dr-xr-xr-x 1 user user 4096 Nov 12 13:05  Default
lrwxrwxrwx 1 user user   20 Apr  1  2024 'Default User' -> /mnt/c/Users/Default
drwxrwxrwx 1 user user 4096 Nov 12 12:51  Public
-r-xr-xr-x 1 user user  174 Apr  1  2024  desktop.ini

[schlichtanders]

It is about using podman with lokal volume bounds from another wsl (e.g. Ubuntu default wsl)

[arixmkii]

@schlichtanders Thank you for clarification. Yeah, this thing will be tricky a lot more tricky. Let's see if someone has any additional input.

[reynoldsbd]

I'd like to share my use case, which I believe would benefit from this feature. I'm exploring the use of Podman as the backend for VS Code Dev Containers as a more stable alternative to Docker Desktop (which seems to break hopelessly with every "minor" update).

Host machine is Windows, and my team's general workflow is to clone our code into WSL, then launch Dev Containers from within WSL. We've found this to have dramatically better performance than cloning directly on NTFS. Unfortunately this scenario doesn't work with Podman today because it requires the ability to transparently bindmount a folder from within my normal (non-Podman) WSL2 distribution into the Dev Container.

Happy to discuss my scenario in greater depth if that is helpful!

[rdbisme]

Would a native SSHFS based integration solve this? When running podman-remote it will create a SSHFS mount on the podman machine VM from the origin WSL, which will allow to mount bind?

[reynoldsbd]

I would be concerned about performance. As Dev Container users, my team cares deeply about build performance within the container, and file system performance is in my experience the most important factor by far in determining the speed of a modern software build.

Granted I don't have any explicit data on hand, but it stands to reason that an SSHFS mount could turn out to be substantially slower than using a DrvFs mount from /mnt/.

There's also the logistics of setting up authentication for the SSH connection. Maybe there is a way to handle this transparently so the user doesn't have to manage, but again it feels unnecessary when the files in question are already mounted under /mnt/.

[computator]

Docker desktop bind mounts directories from other WSL instances into a subdirectory of /mnt/wsl/ which WSL shares across all the WSL instances. This makes whatever directories they mount directly available to the docker WSL instance. This simplifies things and eliminates all performance impacts. I think we should use a similar technique with Podman (or podman desktop).

[computator]

Oh, this is also how Docker Desktop shares the various CLI binaries with other WSL instances

[rdbisme]

Ok thanks. THen a mechanism to translate the -v <path> to -v /mnt/wsl/folder/<path> must be implemented I guess?

[computator]

Yes, both translation as well as the bind mounting and unmounting (as necessary) of the paths.

[l0rd]

I am cross-posting a comment I made in #21813. Hopefully someone here can jump in and help me with this.

I assume the use case involves mounting the content of a folder from a WSL instance (not the podman-machine WSL instance, a distinct one) within a container.

That implies that:

1. The WSL instance file system is bind-mounted in \\wsl$ (for example via /etc/fstab under /mnt/wsl/instances/$WSL_DISTRO_NAME)
2. The podman client transforms a WSL path (e.g., /home/bingo/myWork) into the path under the \\wsl$ mount (e.g., /mnt/wsl/<distroname>/home/bingo/myWork)

@bingoct @EdanBrooke @D1StrX, am I correct? And how does the podman client determine that /home/bingo/myWork needs to be translated and is not local to the podman machine's file system?

[l0rd]

I am closing this issue as it appears to be a duplicate of #21813. @schlichtanders feel free to re-open if that's not the case.