在 Windows 上，当我查看远程文件夹的权限时，帐户具有机器名或域的资格，即帐户名的权限。
在 Linux 上，如果我有一个挂载到远程驱动器的 VM，并且挂载上的文件夹的所有者是“root”，那么这是我的根还是远程系统的根？
在 Linux 上，这一切似乎都太简单了，只要涉及到网络，就无法正常工作。我显然忽略了一些东西。
路加
答案1
不幸的是，这是 Unix 上文件共享最令人困惑的事情之一。而我不擅长解释令人困惑的事情。
你看在ls -l输出中（例如），是从本地系统的角度翻译的远程用户的 ID。
当程序ls使用标准函数查找文件信息时，文件系统驱动程序只能为其提供数字用户 ID，而不是文本名称。（到目前为止，与 Windows 没有太大区别。）要将 UID 转换为名称，ls需要调用完全不同的操作系统组件，即名称服务库，该库不知道 UID 是从哪里获得的，因此只能转换操作系统知道的帐户，但不能回头向文件系统驱动程序寻求帮助。（这就是差异所在。）
例如，如果服务器有两个文件，一个由 root (UID 0) 拥有，另一个由 Luke (UID 1000) 拥有，则ls只会知道它们由“0”和“1000”拥有，并且会查找当地的具有相同 UID 的帐户。“0”始终是 root，但“1000”可能是 Luke，也可能不是。如果 UID 属于存储在 LDAP 或 NIS 或 AD 中的帐户，并且如果客户端操作系统实际上是配置在 LDAP 中查找用户帐户，它会给出正确的用户名。否则它实际上可能会撒谎，因为本地帐户 UID（1000、1001 等）往往对应于不同计算机上的不同人。
（文件系统驱动程序可以通过“扩展属性”的形式告诉程序完整的用户名。不幸的是，尽管进行了各种尝试，但没有标准的方法来做到这一点，并且程序通常ls会尝试避免特定于文件系统的技巧。更不幸的是，并非所有网络文件系统协议能传输用户名：CIFS 又名 SMB 可以，NFSv4 可以，但大多数其他的不能。）
但这些都不重要，因为你可以做文件的权限始终由服务器知道的内容而不是客户端看到的内容决定。例如，如果您使用sshfs，它会使用您的用户名（例如 ）通过 SSH 登录服务器sshfs luke@fileserver，并且服务器不会让您做任何您不应该做的事情。CIFS、AFS 等也是如此。
答案2
所有者是远程计算机上的 root 用户。如果您希望以 root 身份访问远程计算机上的该文件夹，则必须以 root 身份将其挂载到远程计算机上。
换句话说，这应该可以工作（本地用户 aye，远程用户 root）：
aye@ayes-machine$ sshfs root@bees-machine:/path /local-path
这不起作用（本地用户root，远程用户bee）：
aye@ayes-machine$ sudo sshfs bee@bees-machine:/path /local-path