Wrong WSL instance chosen for auto-mount

[Clockwork-Muse]

Version: 1.92.0 (user setup) Commit: b1c0a14de1414fcdaa400695b4db1c0799bc3124 Date: 2024-07-31T23:26:45.634Z Electron: 30.1.2 ElectronBuildId: 9870757 Chromium: 124.0.6367.243 Node.js: 20.14.0 V8: 12.4.254.20-electron.0 OS: Windows_NT x64 10.0.22621 Remote OS Version: Alpine 3.20.0 (Docker Desktop) Remote Extension/Connection Type: Containers + WSL

• Logs: remoteContainers-2024-08-07T23-20-35.090Z.log

Steps to Reproduce:

1. Install any distro on WSL.
2. Install Docker Desktop (or presumably Podman Desktop)
3. Ensure that the default distro is not the docker/podman distro
4. Attempt to set up a devcontainer.

When attempting to start a container - including recovery containers - and the default distro is anything other than the actual target distro, the wrong distro is chosen for the "auto" mounts like X11/wayland.

Obviously, this can be worked around by changing the default distro, or disabling the auto mounting behavior, but this is unfriendly. Preferably the extension could detect the correct distro and respond accordingly.

Does this issue occur when you try this locally?: Yes Does this issue occur when you try this locally and all extensions are disabled?: Yes

[chrmarti]

You can set the distro that should be used in the user settings:

[Clockwork-Muse]

I'm aware of that option as well, but that falls into setting the default WSL distro - it's unfriendly if I use multiple WSL distros, especially concurrently (As is the fact that the docker/podman settings are system wide, not per-profile).

The intent is that I not need to set any similar option when spinning up a container.

[vs-code-engineering[bot]]

Hey @chrmarti, this issue might need further attention.

@Clockwork-Muse, you can help us out by closing this issue if the problem no longer exists, or adding more information.

[Clockwork-Muse]

Issue persists on:

Version: 1.96.2 (user setup)
Commit: fabdb6a30b49f79a7aba0f2ad9df9b399473380f
Date: 2024-12-19T10:22:47.216Z
Electron: 32.2.6
ElectronBuildId: 10629634
Chromium: 128.0.6613.186
Node.js: 20.18.1
V8: 12.8.374.38-electron.0
OS: Windows_NT x64 10.0.22631

[chrmarti]

I'm aware of that option as well, but that falls into setting the default WSL distro - it's unfriendly if I use multiple WSL distros, especially concurrently (As is the fact that the docker/podman settings are system wide, not per-profile).

The intent is that I not need to set any similar option when spinning up a container.

@Clockwork-Muse That option only applies when the distro is not given by the folder you are opening in the container. E.g., when opening a Windows folder, a Docker volume or a recovery container. It does not apply when you open a WSL folder in some other distro in a container.

Wouldn't that match your case?

[Clockwork-Muse]

.... okay, so what happens when all distros are being used with docker volume mounts/recovery containers (or "New Devcontainer", which also creates a volume by default).

If I'm running both Docker Desktop and Podman Desktop, I have to use volume with both of them, and I've been using trying to use volumes with any other "manual setup" distros as well (it's a great way to keep you honest about storage).

[chrmarti]

It seems you are asking for a way to configure which distro to use for each dev container?

[Clockwork-Muse]

Not necessarily.
This particular issue is about the fact that the distro chosen for the automounts does not match the distro chosen to host the devcontainer itself.

[chrmarti]

Your log file shows the Ubuntu distro being used for both or I'm missing something? Could you share a log that shows different distros being used for automount and container?

[Clockwork-Muse]

That is a log from such a scenario. In the log file presented, the docker context is desktop-linux, which is the docker desktop context:

C:\Users\xande>docker context ls
NAME              DESCRIPTION                               DOCKER ENDPOINT                             ERROR
default           Current DOCKER_HOST based configuration   npipe:////./pipe/docker_engine
desktop-linux *   Docker Desktop                            npipe:////./pipe/dockerDesktopLinuxEngine

Doing something like Ctrl+Shift+P -> Dev Containers: New Dev Container... causes the extension to download the image and create the volume on the docker context (so on the docker desktop distro) and try to bring up the container, but it fails because it used the default distro to find the mount... which don't actually exist on the distro the context is referring to.

My default distro doesn't have the volume created, nor the base image downloaded. If I turn off the Wayland auto-mount, it creates the devcontainer and runs on my Docker Desktop distro, not my default WSL distro.

For that matter, it starts my default WSL distro, even though it probably shouldn't have to....

[chrmarti]

I'm confused: There is a default_context in Docker and a default_distro in WSL. Dev Containers should only work with the current context which is desktop-linux locally in your case. For Dev Containers: New Dev Container... it should use the default distro and whatever the current Docker context is in that WSL distro.

[Clockwork-Muse]

Dev Containers: New Dev Container works with the context from the windows side (by default, at least - you can create devcontainers on non-default distros by opening folders on those filesystems, of course). It has to - the context might refer to a remote machine.

Even if the docker-desktop distro is the default one, there's no docker context from inside that distro; attempting to call docker yields:

It looks like you have tried to invoke the docker CLI from the docker-desktop WSL2 distribution. This is not supported.

Please invoke the docker CLI from the Windows Command Prompt, PowerShell, or other compatible terminals.

If you wish to interact with Docker Desktop from a third-party WSL2 distribution, such as Ubuntu, please enable the Docker Desktop WSL2 integration for it. See: https://docs.docker.com/desktop/wsl/#enabling-docker-support-in-wsl-2-distros

... and there's no DOCKER_CONTEXT environment variable, /var/run/docker.sock doesn't exist, etc.

You'd have to somehow figure out which distro is being used from the context...

[vs-code-engineering[bot]]

Hey @chrmarti, this issue might need further attention.

@Clockwork-Muse, you can help us out by closing this issue if the problem no longer exists, or adding more information.

[Clockwork-Muse]

Yes, this problem still exists.