Join Log in
Score:1
avatar Ubuntu

Unable to open visual studio code when inside sshfs mounted drive UBUNTU WSL

ru flag
Kurt Rojas

I've been having trouble with opening visual studio code.

The scenario is that I have a server filesystem mounted in my local pc (UBUNTU WSL) using SSHFS.

In normal cases, I can open file using visual studio code using the command code <filename>.
However, when I am inside the server filesystem directory and I try to use this command I get the error

/mnt/c/Users/kurti/AppData/Local/Programs/Microsoft VS Code/Code.exe: Invalid argument

Surprisingly, I can use gedit in the same manner without any problem e.g. gedit <filename>.

Then what is weird is that I can use the code to open a file/directory in the server filesystem when I am any folder in my local fileystem. With this I can easily open the server file using code </full/path/to/file>.

Is this a possible bug in visual studio code or a problem with my system ?

Edit: I created a new work around function/command which is
command name: vcode

#!/bin/bash
fpath=$(realpath $1)
(cd $HOME; code fpath)

Update: I reported it in the WSL github page as an issue https://github.com/microsoft/WSL/issues/7890

More specific details as follows

Repo steps

In WSL terminal,

  1. Mount a server filesystem using sshfs (in my case it is a university supercomputer)
    sshfs -C <server_name_and_ip> <mount_location>
    designated mount_location is an empty directory called smith_server with path /home/k/smith_server/
  2. Go to directory cd /home/k/smith_server
  3. Open directory in visual studio code code .

Expected behavior

The expected behavior is that visual studio will open the directory/file regardless of the current working directory.

Actual behavior

The actual behavior is that when the current working directory is inside the mounted server filesystem, launching the command code . or code <filename> will result in the error code.

/mnt/c/Users/kurti/AppData/Local/Programs/Microsoft VS Code/Code.exe: Invalid argument

Some examples that are working,

  1. When the working directory is not part of the mounted server filesystem, code . or code <file> works fine.
  2. When the working directory is not part of the mounted server filesystem, using code to a full path of a file/directory in the server filesystem e.g. code /home/k/smith_server can successfully open the file/directory without problems.
  3. When the working directory is inside the mounted server filesystem, gedit <file> works fine
  4. When the working directory is inside the mounted server filesystem, code $HOME also gets an error.

The conclusion on my end is that there are problems when invoking code command when inside the mounted server filesystem. Additionally, this doesn't happen when gedit was used. However, when outside the mounted server filesystem, the code command can be invoked and also access the mounted filesystem by using a full path. Perhaps for something is happening when tracing the Code.exe file. Linux-based software like gedit is not affected but perhaps the Windows-based software like Code.exe, that are just being interfaced are affected?

143
0 + 0
cocomac avatar
cn flag
cocomac
This might be a bug with how VS Code works in WSL. I suggest [filing an GitHub issue](https://github.com/microsoft/WSL/issues/new?assignees=&labels=&template=Bug_Report.yaml) to report this.
0
Reply
NotTheDr01ds avatar
vn flag
NotTheDr01ds
I'll try to give this a try on my system later today. Good to see you at least have a workaround.
0
Reply
ru flag
Kurt Rojas
@cocomac Thanks for the suggestion. I submitted a report on the github.
1
Reply
ru flag
Kurt Rojas
@NotTheDr01ds Thanks, you can see the more specific steps in the update or in the issue I submitted in github
0
Reply
Score:2
NotTheDr01ds avatar Ubuntu
vn flag
NotTheDr01ds

I was able to reproduce this quite readily.

Solution:

  • Unmount the existing fuse mount:

    fusermount -u /home/k/smith_server

  • Edit /etc/fuse.conf as root:

    sudo -e /etc/fuse.conf

  • Uncomment the user_allow_other option

  • Remount with the allow_root option:

    sshfs -o allow_root [user@]<remote_server>:/path /home/k/smith_server

More Details:

Note that this isn't just a problem with sshfs. You'd run into it when launching VSCode from within any fuse-based mount point.

I'm honestly not quite sure of the root cause here, but ...

You'll notice that, without the above solution in place, if you attempt to browse to \\wsl$\Ubuntu\home\k\smith_server\, you won't be able to enter that directory. You'll have access to your home directory, but you won't be able to access smith_server.

That tells me that even though Windows/WSL enforces permissions for your user when browsing (by default, unless you override this in /etc/wsl.conf), it still seems to be doing so as root in the background.

So, once we figure this out, it's no surprise that VSCode can't handle being launched from a directory which, to it, doesn't exist.

This works when you launch it from $HOME because VSCode initializes, then switches to the "Remote - WSL" extension, which communicates with the VSCode server that was installed in your WSL instance (in ~/.vscode-server). Once that happens, it's accessing the fuse-mounted filesystem as your user, and everything's happy.

Per man fuse:

No other user (including root) can access the contents of the mounted filesystem.

But, there is the option to override this with either -o allow_other or -o allow_root. And to enable either of these, the aforementioned /etc/fuse.conf option needs to be set appropriately.

Then, VSCode has proper access to the directory when launching.

You'll also see that you can now browse, via Windows, to \\wsl$\Ubuntu\home\k\smith_server\.

0 + 0
ru flag
Kurt Rojas
Thank you very much for the effort. It actually helped!
1
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.