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

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\.