WSL_INTEROP access in .devcontainers from WSL

[jgueytat]

@chrmarti Could you reopen the issue?

Hi, in my use case, I open WSL through VSCode Remote WSL, and then, I go into my container through VSCode Remote Container.
The WSL_INTEROP does not change here, I just want to pick the variable from the WSL environment I already have and which is launching docker.

Best Regards,

Originally posted by @meskill in #8026

[jgueytat]

Here are the options that make it work :

    "runArgs": [
        "--privileged"
    ],
    "mounts": [
        "type=bind,source=/mnt/c,target=/mnt/c",
        "type=bind,source=/run/WSL,target=/run/WSL",
        "type=bind,source=/init,target=/init,readonly"
    ],

And there is also another trick about the path :

#!/usr/bin/env sh

[ -f "$1" ] || exit 0

cd "$(dirname $1)"
./$(basename $1)

Launching an application will only work if you are inside the folder somehow.

/mnt/c/Windows/system32/notepad.exe => ko
cd /mnt/c/Windows/system32/ && ./notepad.exe => ok

With this script, I have to run : ./cmd.sh /mnt/c/Windows/system32/notepad.exe

A nicer wrapper could be written. I just picked the simplest to show the trouble here.

List of stuff to check :

• mounting /mnt/c
• check the variable WSL_INTEROP (just set the same value than the one in WSL inside the container)
• access to init (don't know if it's normal)
• run with privileged mode
• fix the path trouble

Hope it's going to be smoother.

[vs-code-engineering]

This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 10 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!