Support WSL mount options with vscode remote

[bastianaf]

when i try to connect by wsl-remote i got

sh: 1: /mnt/c/Users/Bastian/.vscode-insiders/extensions/ms-vscode-remote.remote-wsl-0.42.0/scripts/wslServer.sh: Permission denied

[jabdr]

I have the same problem. It comes from my custom wsl.conf options:

[automount]
root = "/"
options = "metadata,uid=1000,gid=1000,umask=22,fmask=111"

With the default settings all files in the windows filesystem are executable. With this wsl configuration they are not (I need it for git).

vscode should rather call /usr/bin/env sh /path/to/wslServer.sh instead of running wslServer.sh directly. Then it could chmod +x all files in the scripts directory.

Regards

[bastianaf]

sudo chmod +x * on scripts directory (/.vscode-insiders/extensions/ms-vscode-remote.remote-wsl-0.42.0/scripts/) works for me, thanks.

Regards

[jabdr]

@bastian-af But you have to run this on every update of the extension... Please reopen it

[clement-fischer]

I have the same problem. It comes from my custom wsl.conf options:

[automount]
root = "/"
options = "metadata,uid=1000,gid=1000,umask=22,fmask=111"

With the default settings all files in the windows filesystem are executable. With this wsl configuration they are not (I need it for git).

vscode should rather call /usr/bin/env sh /path/to/wslServer.sh instead of running wslServer.sh directly. Then it could chmod +x all files in the scripts directory.

Regards

I have the same configuration, I think this fmask setting is quite standard, it should be supported by the extension.

[bamurtaugh]

Hey there, thanks for opening this issue. Are you still experiencing this problem? If so, it might make sense to change the title of the issue to something a bit more specific to what appears to be the request here. Thank you! 😄

[jabdr]

@bamurtaugh A better title would be something like "Support WSL mount options with vscode remote"

The reason for the wsl.conf is to have a better linux like feeling accessing files on the windows file system. Also some linux applications require specific restrictive permissions on files.

I think the change is quite minor, because vscode just have to run a bash -c 'chmod +x /path/to/scripts/*' before running the vscode server,

OR

run the first script with

bash /path/to/scripts/script.sh

and then the script itself can run chmod +x /path/to/scripts/*

[jabdr]

@bamurtaugh Oh, I forgot to say that I still have this issue with the latest version after every update of the wsl remote.

[bamurtaugh]

@jabdr Thanks for the additional info! Your title suggestion makes sense, so I adjusted the name accordingly to help with issue tracking.

[CzBiX]

The title should include keyword "metadata".

[cyraid]

Any update to this? :)
Edit: Could you not just run a chmod u+x or something?

[jpfarias]

Still no fix for this?

[Sean12mps]

Can confirm that this is still happening by setting
[automount]
root = "/"
options = "metadata,uid=1000,gid=1000,umask=22,fmask=111"

[bendem]

Came here after setting my wsl automount's fmask to a saner default than "everything executable" and yeah, it's a really simple fix for the extension, remove -c in the launch command. In my case:

# replace
C:\windows\System32\wsl.exe -d RockyLinux8 sh -c '"$VSCODE_WSL_EXT_LOCATION/scripts/wslServer.sh" x stable code-server .vscode-server --host=127.0.0.1 --port=0 --connection-token=x --use-host-proxy --without-browser-env-var --disable-websocket-compression --accept-server-license-terms --telemetry-level=all'

# with
C:\windows\System32\wsl.exe -d RockyLinux8 sh -- "$VSCODE_WSL_EXT_LOCATION/scripts/wslServer.sh" x stable code-server .vscode-server --host=127.0.0.1 --port=0 --connection-token=x --use-host-proxy --without-browser-env-var --disable-websocket-compression --accept-server-license-terms --telemetry-level=all

Same for the content of that script, replace "$(dirname "$0")/wslDownload.sh" with sh "$(dirname "$0")/wslDownload.sh".

[Almenon]

@bendem where can I find the launch command to alter?

Sidenote: @bamurtaugh I would suggest labeling this as a bug. The issue prevents WSL extension from working.

[bendem]

@bendem where can I find the launch command to alter?

I had to dig through logs and code to find it and I forgot how. It's more of a note to the devs than a workaround aimed at users. The fix is really simple on their side, pass the script to bash directly instead of relying on it being executable.

I'm not sure what's taking so long unless no dev actually ever looked at this issue.

[kkm000]

@bastianaf:

sudo chmod +x * on scripts directory (/.vscode-insiders/extensions/ms-vscode-remote.remote-wsl-0.42.0/scripts/) works for me, thanks.

Works for me too, but I have to do that every time the WSL extension is upgraded. Quite an inconvenience, mildly speaking. Thanks MS, but no, I'll better use Linux over SSH. WSL2 integration with VSCode has been borked for years.

@bamurtaugh:
Thank you for reopening the issue. It is an issue. Like many people, I have in my /etc/wsl.conf

~$ cat /etc/wsl.conf
[automount]
options = "metadata,umask=22,fmask=111"

Without this settings, all files listed on Windows drive mounts are executable for the WSL2 kernel, and ls -l shows them in bright green with an asterisk on end of the filename. This is not a sane default, with all respect. Precisely as @bendem well said, “Came here after setting my wsl automount's fmask to a saner default than "everything executable".” For one, as @jabdr notes, it breaks git inside WSL2 when it looks at files on a Windows volume, because git includes a subset of access bits into a commit, and thinks all files are modified immediately after cloning a repo.

Now, the fix is extremely simple. The error occurs because the .sh files that VSCode attempts to execute using wsl.exe don't have extended WSL2-specific metadata stored in NTFS extended attributes to indicate that they're executable for WSL2. They can be, however, executed explicitly by giving them as an argument to the shell, exactly as @bendem pointed out in the comment above.

@bamurtaugh, I beg you on my knees, pretty please, bump the priority of this issue. It's a two character change, that hasn't been applied in three years and nine months. Can anyone find some free cycles to change one character every 22 months? I had to give up WSL2 development as I have enough Linux boxes at home base, but when I'm on the move, all I have is my notebook. And the WSL2 plugin is updated at least three times a week¹, so I have to curse and run the damn chmod +x /.vscode/extensions/ms-vscode-remote.remote-wsl-XXXXXXX/scripts/*, whatever path of the day is printed in the VSCode's Output window error message (XXXXXXX varies, impossible to automate). A two character patch. Just two characters, and WSL2 development turns into an attractive and convenient option from the last resort option, as it stands now. Is it so hard to squeeze this tiniest fix into pipeline? So many people would be grateful!

Footnotes

1. Which I'm unable to fit into my feeble mind: a blocker issue, fixable in about thee minutes, is open for nearly 4 years, while other changes flow in a deluge. ↩

[bendem]

whatever path of the day is printed in the VSCode's Output window error message (XXXXXXX varies, impossible to automate).

chmod +x /mnt/whatever/.vscode/extensions/ms-vscode-remote.remote-wsl-*/scripts/*.sh would work every time unless I'm missing something.

[markeissler]

chmod +x /mnt/whatever/.vscode/extensions/ms-vscode-remote.remote-wsl-*/scripts/*.sh would work every time unless I'm missing something.

I think you're missing the fact that every time the extension is updated the command has to be run again.