在 Synology NAS 上使用 NFS 映射用户 ID

Rog*_*mbe 26 nfs synology-diskstation

我有一个 Synology NAS 盒子(运行 DSM 5.1),并且我已经通过 NFS 导出了一个目录。我正在尝试将它安装在我的 Ubuntu 机器上。

它大多工作正常,但我遇到了用户和组映射问题。在 Ubuntu 机器上,我是 uid 1000 (roger),gid 1000 (roger)。在 Synology 上,我有 uid 1026 (roger), group 100 (users)。

如果我使用 NFSv3,它使用数字 uid/gid 值,这意味着所有权在 Synology 上混乱。

如果我只使用同一个用户从同一个 Ubuntu 机器访问 NFS 挂载,这很好,但我也从 Windows 机器访问目录,使用 CIFS (SMB),这意味着权限是错误的。

如果我使用 NFSv4 ( mount -o nfsvers=4),并使用Synology 上的默认设置,则在从 Ubuntu 框中查看时roger.users,Synology 上的文件显示为所有roger.users。这很好。

但是,当我touch一个文件时:

roger@ubuntu$ touch /mounts/diskstation/music/foo
Run Code Online (Sandbox Code Playgroud)

它最终1000.1000在 Synology上归归所有,并nobody.4294967294在从 Ubuntu 框中查看时显示为归归归所有。

我在 Synology 论坛上可以找到的关于该主题的所有内容都可以追溯到 2011 年,当时不支持 NFSv4,或者由提出相同问题然后放弃的人组成。

为完整起见,/etc/exports有:

/volume1/music  10.0.0.0/24(rw,async,no_wdelay,root_squash,insecure_locks,sec=sys,anonuid=1025,anongid=100)
Run Code Online (Sandbox Code Playgroud)

...我将它安装在 Ubuntu 盒子上:

mount -t nfs diskstation:/volume1/music /mounts/diskstation/music/ -o rw,nfsvers=4
Run Code Online (Sandbox Code Playgroud)

我发现了一些提示,这sec=sys可能是一个问题:为什么 NFSv4 uid/gid 映射不适用于 AUTH_UNIX (AUTH_SYS),但这没有解决方案。

有没有一种简单的方法可以解决这个问题?有没有更复杂的(Kerberos)方法来解决这个问题?

说真的,如果 Kerberos答案,我会接受这个打击,但我想在浪费大量时间之前知道。

更新:虽然Synology 文档讨论了各种 Kerberos 选项,但我在 UI 中找不到它们。该发行说明状态:“如果Kerberos安全风味实现......”。我发现(但无法再次找到)一个页面,这意味着它可能不在某些型号上。根据系统信息页面,我有一台 DS211。也许我运气不好?

sup*_*ami 14

要使 NFSv4 ID 映射正常工作,客户端和服务器都必须运行idmapdID Mapper 守护程序并Domain/etc/idmapd.conf.

通过这种方式,您的 NFS 客户端将其 ID 凭据发送roger@example.com到网络上的 NFS 命令中,并且您的 NFS 服务器 idmapper 将其映射到roger在 NFS 服务器上调用的用户。UID 和 GID 无关紧要,它们由 idmapper 映射到每个系统上。

但是,我不介意我的 Synology 上的这些。我的共享文件夹具有以下权限:

  • 权限
    • 本地用户
      • 管理员 = 读/写
  • NFS 权限
    • 壁球
      • 将所有用户映射到管理员

这会导致anonuid=1024,anongid=100admin用户和users组)被添加到/etc/exportsNAS的导出中。

我的 NFS 客户端(没有运行 ID 映射器)以我的用户 ( 1000:1000)的身份发送我的 NFS 命令,并且因为该 UID 和 GID 在 NAS 上不存在,它将我的 UID 和 GID 转换为1024:100所以我被视为具有完全权限的管理员用户。

这是在商业环境中非常不专业和不安全地使用 NFS,但对于我在家访问我的文件来说,这是对 NFS 行为的滥用,这对我来说是可以接受的。

另一种选择是roger在 NFS 客户端和 NAS 上使的 UID 和 GID 相同,然后您可以使用 NFSv4 而不使用 ID 映射,或者您可以使用仅依赖 UID 和 GID 的 NFSv3。

  • 这可能是宇宙中唯一为不需要 NFS 在网络环境中提供的完整安全性的家庭 Linux 用户提供合理解决方案的地方。适用于 Ubuntu 19.4 和 DSM 6.2.2。 (3认同)

小智 7

我一直在为同样的问题而苦苦挣扎。我经历了在 Synology 上使用 Docker 设置 Kerberos 服务器、设置 ID 映射的巨大痛苦,但我仍然不喜欢这种行为。Kerberos 的设计过于过度,很难在重新启动和自动挂载时继续工作。另外,新创建文件的默认 umask 是 0000,每个新文件的创建模式都是 777,无论我本地的 umask 是多少。

我的解决方案与 suprjami 的类似,但我更进一步:

  • 使用 Synology Web UI 创建一个新用户,将其命名为roger.remote. 对用户组执行相同操作,并将其命名为与用户名相同的名称。
  • 在 Synology 上以 root 身份编辑 /etc/passwd 并将roger.remote的 UID 更改为 1000,将 GID 更改为 1000
  • 编辑/etc/group并将组roger.remote也更改为1000
  • 在 Synology Web UI 中,将squash 设置为“所有用户为管理员”并保存
  • 再次以 root 身份编辑 /etc/exports 并将 UID/GID 更改为anonuid=1000,anongid=1000
  • 重新启动 NFS/usr/syno/etc.defaults/rc.sysv/S83nfsd.sh restart
  • 这也有点老套——但是chmod 777 /volume1。我的主目录安装时遇到了很多奇怪的问题。KDE 无法启动,因为 glibcaccess()函数将返回对已安装 NFS 目录的访问被拒绝。(但任何子目录都可以)Firefox 也有类似的问题,由于访问检查,它拒绝将文件保存到安装的目录中。即使权限是正确的,我也可以在安装的目录中触摸/创建/写入文件。将父 /volume1 目录更改为全局可写解决了这个愚蠢的问题并欺骗客户端应用程序写入它。
  • 从共享中删除所有文件系统 ACL。通过大量随机实验,我发现这些 ACL 会导致创建的文件的模式掩码出现问题。我不是 ACL 大师,所以也许有更优雅的解决方案。作为 Synology 的 root 用户,请执行synoacltool -del /volume1/myshare。您应该看到该+符号已从 ls -l 输出中删除。
  • 将共享的所有权更改为新用户:chown roger.remote:roger.remote /volume1/myshare
  • 将模式更改为 755:chmod 755 /volume1/myshare
  • 在客户端上安装该卷,测试权限,它应该可以工作!确保同时触摸文件并验证您的 bash umask 是否正确应用。
$ 掩码
0002
$ cd /mnt/myshare
$ 触摸测试
$ ls -l 测试
-rw-rw-r-- 1 罗杰罗杰 0 10 月 21 日 18:15 测试

在 Synology 上您应该看到:

# ls -l /volume1/myshare/test
-rw-rw-r-- 1 roger.remote roger.remote 0 10 月 21 日 18:15 测试

享受!