I have Ubuntu 20.04 with WSL2 and created a new user with sudo privileges:

sudo adduser newuser
sudo usermod -aG sudo newuser
su - newuser

Windows does not seem to have permission to write in the new user folder. Here with Visual Studio Code:

touch test.txt
code test.txt

and then writing something and trying to save will ask me to try and do it as admin, which I do and then get this error message:

Failed to save 'test.txt':
Command failed: "C:\Users\<username>\AppData\Local\Programs\Microsoft VS Code\bin\code.cmd" --file-write "c:\Users\<username>\AppData\Roaming\Code\code-elevated-pdtmzg" "\\wsl$\Ubuntu\home\newuser\test.txt"
Error using --file-write: EPERM: operation not permitted, open '\\wsl$\Ubuntu\home\newuser\test.txt'

Here is the result of ls -all with the new user work:

Here is the result of ls -all with the default user hellmers:

Here are the groups for the users. I also tried adding work to the hellmers group:

The only way I manage to get it to work is to give others write privileges through sudo chmod o+w <file>, which shouldn't be necessary?

16

1 Answer

You seem to be running into this issue. Namely, VSCode always runs as the default user in a WSL session.

You should be able to confirm this with a simple whoami in the VSCode terminal. Even though you started it from the work user, it will likely be running as hellmers.

For your particular use case, I would think, you could give your hellmers user access to the work user folder. Seems to work for me:

sudo usermod -aG work hellmers
chmod -R g+wrx /home/work

If you really do need to run VSCode as the work user, per that Github issue, you'll need to change the default user for the WSL instance. The recommended way of doing this is by creating a /etc/wsl.conf (as sudo) with the following contents:

[user]
default=work

Then stopping your WSL instance with wsl --terminate <distroname and restarting.

VSCode should run as the work user at that point.

It's not pretty, nor convenient. But if you must run VSCode as a different user, you'll need to make that user the default for the WSL instance.

Another possible alternative would be to set up separate WSL instances, one with hellmers as the default and the other, of course, with work. There's nothing wrong with keeping around multiple "utility" WSL instances as you need them.

8

Your Answer

Sign up or log in

Sign up using Google Sign up using Facebook Sign up using Email and Password Submit

Post as a guest

Post Your Answer Discard

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy