WSL2: make VS Code Server work with automount disabled

[brawaru]

If you disable automounting of Windows partitions in WSL2 (you can have reasons to do that) through creating

/etc/wsl.conf

[automount]
enabled=false

… the VS Code will then fail to start since it can't copy it's server file from /mnt/c/Users/username/AppData/Local/Temp/vscode-remote-wsl/, since Windows partitions are never mounted.

‘More details’ from terminal

``` [2021-10-24 11:55:23.002] Resolving wsl+ubuntu-mastodon, resolveAttempt: 1 [2021-10-24 11:55:23.077] Starting VS Code Server inside WSL (ubuntu-mastodon) [2021-10-24 11:55:23.077] Extension version: 0.58.2, Windows build: 19042. Multi distro support: available. WSL path support: enabled [2021-10-24 11:55:23.077] No shell environment set or found for current distro. [2021-10-24 11:55:23.225] Probing if server is already installed: C:\Windows\System32\wsl.exe -d ubuntu-mastodon -e sh -c "[ -d ~/.vscode-server/bin/6cba118ac49a1b88332f312a8f67186f7f3c1643 ] && printf found || ([ -f /etc/alpine-release ] && printf alpine-; uname -m)" [2021-10-24 11:55:23.345] Probing result: found [2021-10-24 11:55:23.345] Server install found in WSL [2021-10-24 11:55:23.345] Launching C:\Windows\System32\wsl.exe -d ubuntu-mastodon sh -c '"$VSCODE_WSL_EXT_LOCATION/scripts/wslServer.sh" 6cba118ac49a1b88332f312a8f67186f7f3c1643 stable .vscode-server 0 '} [2021-10-24 11:55:23.461] sh: 1: /scripts/wslServer.sh: not found [2021-10-24 11:55:23.462] VS Code Server for WSL closed unexpectedly. [2021-10-24 11:55:23.462] For help with startup problems, go to [2021-10-24 11:55:23.462] https://code.visualstudio.com/docs/remote/troubleshooting#_wsl-tips [2021-10-24 11:55:23.486] WSL Daemon exited with code 0 ```

I think this can be worked around by accessing WSL filesystem through \\wsl$\distro-name\ and copying WSL scripts over to ~/.vscode-server/scripts (or if it's overwritten with every update of code-server, then maybe in some other directory like ~/.local/lib/vscode-server?) and chmod +x them (there can be a better way, perhaps?), then instead of running them from /mnt/c/..., just execute them from the directory copied. I actually was able to start the server that way:

Command log

```bash ... files copied through explorer here ... chmod +x ~/.vscode-server/scripts/wslServer.sh chmod +x ~/.vscode-server/scripts/wslDownload.sh chmod +x ~/.vscode-server/scripts/wslCode.sh ~/.vscode-server/scripts/wslServer.sh 6cba118ac49a1b88332f312a8f67186f7f3c1643 stable .vscode-server 0 ``` ``` Setting up server environment: Looking for /home/braw/.vscode-server/server-env-setup. Not found. WSL version: 5.10.16.3-microsoft-standard-WSL2 ubuntu-mastodon WSL2-shell-PID: 299 Starting server: /home/braw/.vscode-server/bin/6cba118ac49a1b88332f312a8f67186f7f3c1643/server.sh --port=0 --use-host-proxy --without-browser-env-var --disable-websocket-compression --print-ip-address --enable-remote-auto-shutdown * * Visual Studio Code Server * * Reminder: You may only use this software with Visual Studio family products, * as described in the license https://aka.ms/vscode-remote/license * IP Address: 172.18.89.65 Extension host agent listening on 32987 [19:09:50] Extension host agent started. ```

Although VS Code still wouldn't connect to it (maybe detecting running server isn't a part of the script).

Don't really know how internals work, so this is just a guessing, but I think you get the concept of that idea! :D

[tomrucki]

Is there any workaround? The isolation (keeping the automount off) was one of the selling points for me.

[aeschli]

Unfortunately, no workaround.

[aeschli]

I haven't tried it, but maybe you can use the Remote-SSH extension instead?

[bendem]

If the script was reworked so that those 3 scripts were a single script instead of 3 (functions and selecting what to run with an argument), the extension could pipe the content of that script to sh inside wsl, removing the need to have the host disk mounted inside wsl:

instead of running

wsl.exe -d $distro sh -c '"/mnt/c/.../wslServer.sh" <args...>'

you can

cat "/mnt/c/.../wsl.sh" | wsl.exe -d $distro sh /dev/stdin -- wslServer <args...>

It solves #2126 as well.

[zsmith009]

Still no fix, are you serious? I personally don't want to be mounting my entire c drive as I feel as it can pose a security issue, but if I disable automount, then I can't use vscode with my wsl, which is basically a major issue.

[mio-19]

Still no fix, are you serious? I personally don't want to be mounting my entire c drive as I feel as it can pose a security issue, but if I disable automount, then I can't use vscode with my wsl, which is basically a major issue.

Same here

[kkm000]

@aeschli,

I haven't tried it, but maybe you can use the Remote-SSH extension instead?

WSL2 has no systemd and no services. To launch sshd, you'd have to pipe a command into wsl anyway, and I'm not even sure it will work. Removing WSL2 and installing a Linux HyperV VM is a much better option than WSL2 right now. This does admit an SSH connection. WSL2 was supposed to be simple, but it's not, it requires a manual intervention every time the WSL2 plugin is upgraded, and it's upgraded at an insane pace, a few times a week. See https://github.com/microsoft/vscode-remote-release/issues/2126#issuecomment-1735055330. I'd upgrade the issue from "feature request" to "blocker" if I were you...

[SaturnTsen]

I've encountered the same issue... I am just worried about the security issue of mounting the entire C drive directly onto WSL.

[SaturnTsen]

At present, WSL2 supports ssh connection, also try connecting via ssh.

For an Ubuntu distro, you need to enable systemd at /etc/wsl.conf

[boot]
systemd=true

Then execute wsl.exe --shutdown

Install an openssh server on your WSL

sudo apt install openssh-server
sudo sed -i -E 's,^#?Port.*$,Port 2022,' /etc/ssh/sshd_config
sudo service ssh restart
sudo sh -c "echo '${USER} ALL=(root) NOPASSWD: /usr/sbin/service ssh start' >/etc/sudoers.d/service-ssh-start"
sudo /usr/sbin/service ssh start

Then execute hostname -I in wsl.

Finally, connect to wsl via SSH using the correct hostname and port.

I tried using localhost to connect but this s**ks since the address of the virtual network of wsl is not 127.0.0.1, and it seems that you need to check for the correct hostname every time you starts your wsl distro.