☰

在 sshfs 安装驱动器 UBUNTU WSL 中无法打开 Visual Studio 代码

tag-icon • tag-icon 20.04 bash windows-subsystem-for-linux visual-studio-code sshfs
在 sshfs 安装驱动器 UBUNTU WSL 中无法打开 Visual Studio 代码

我在打开 Visual Studio 代码时遇到了麻烦。

场景是我使用 SSHFS 在本地电脑（UBUNTU WSL）上安装了服务器文件系统。

在正常情况下，我可以使用命令使用 Visual Studio Code 打开文件code <filename>。
但是，当我在服务器文件系统目录中并尝试使用此命令时，出现错误

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

令人惊讶的是，我可以以相同的方式使用 gedit 而没有任何问题，例如gedit <filename>。

然后奇怪的是，当我在本地文件系统中的任何文件夹中时，我可以使用代码打开服务器文件系统中的文件/目录。这样，我可以轻松使用 打开服务器文件code </full/path/to/file>。

这是 Visual Studio 代码中的可能错误还是我的系统存在问题？

编辑：我创建了一个新的函数/命令，其
命令名称为：vcode

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

更新：我在 WSL github 页面上将其报告为一个问题https://github.com/microsoft/WSL/issues/7890

具体细节如下

回购步骤

在 WSL 终端中，

  1. 使用 sshfs 挂载服务器文件系统（在我的例子中，它是一台大学超级计算机）
    sshfs -C <server_name_and_ip> <mount_location>
    指定的 mount_location 是一个名为 smith_server 的空目录，其路径为/home/k/smith_server/
  2. 转至目录cd /home/k/smith_server
  3. 在 Visual Studio Code 中打开目录code .

预期行为

预期的行为是，无论当前工作目录如何，Visual Studio 都会打开目录/文件。

实际行为

实际行为是，当当前工作目录位于已挂载的服务器文件系统内时，启动命令code .或code <filename>将导致错误代码。

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

一些有效的例子，

  1. 当工作目录不是已挂载服务器文件系统的一部分时，code .或者code <file>工作正常。
  2. 当工作目录不是已挂载的服务器文件系统的一部分时，使用代码获取服务器文件系统中文件/目录的完整路径（例如）code /home/k/smith_server可以成功打开该文件/目录而不会出现问题。
  3. 当工作目录位于已安装的服务器文件系统内时，gedit <file>工作正常
  4. 当工作目录位于已挂载的服务器文件系统内时，code $HOME也会出现错误。

我的结论是，在已安装的服务器文件系统内调用 code 命令时会出现问题。此外，使用 gedit 时不会发生这种情况。但是，在已安装的服务器文件系统之外时，code可以调用该命令，也可以使用完整路径访问已安装的文件系统。也许是因为在跟踪 Code.exe 文件时发生了一些事情。基于 Linux 的软件（如 gedit）不受影响，但也许刚刚被接口的基于 Windows 的软件（如 Code.exe）会受到影响？

答案1

我能够很轻松地重现这一点。

解决方案：

  • 卸下现有的保险丝座：

    fusermount -u /home/k/smith_server

  • 以 root身份编辑/etc/fuse.conf：

    sudo -e /etc/fuse.conf

  • 取消注释该user_allow_other选项

  • 使用以下allow_root选项重新挂载：

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

更多细节：

请注意，这不仅仅是 的问题sshfs。在 VSCode 内部启动时，你也会遇到这个问题任何 fuse- 基于挂载点。

说实话，我不是相当确信这里的根本原因，但是......

您会注意到，如果没有上述解决方案，如果您尝试浏览\\wsl$\Ubuntu\home\k\smith_server\，您将无法进入该目录。您可以访问您的主目录，但无法访问smith_server。

这告诉我，即使 Windows/WSL 强制执行你的用户浏览时（默认情况下，除非您在中覆盖此功能），它似乎仍在后台/etc/wsl.conf执行此操作。root

因此，一旦我们弄清楚了这一点，VSCode 无法处理从不存在的目录启动就不足为奇了。

这作品当您从启动它时$HOME，因为 VSCode 会初始化，然后切换到“Remote - WSL”扩展，该扩展与安装在 WSL 实例中的 VSCode 服务器通信（在 中~/.vscode-server）。一旦发生这种情况，它就会访问 fuse 挂载的文件系统，如下所示你的用户，一切都很愉快。

每man fuse：

没有其他用户（包括 root）可以访问已挂载文件系统的内容。

但是，可以使用 或 来覆盖此功能-o allow_other。-o allow_root要启用其中任何一个，/etc/fuse.conf需要适当设置上述选项。

然后，VSCode 在启动时就可以正确访问该目录。

您还将看到，现在可以通过 Windows 浏览\\wsl$\Ubuntu\home\k\smith_server\。

相关内容