☰

nfs 在 Linux 客户端上为所有用户安装 rw nexenta 共享 - 失败

tag-icon • tag-icon linux nfs readwrite
nfs 在 Linux 客户端上为所有用户安装 rw nexenta 共享 - 失败

情况：

我们正在使用 Nexenta 设备进行 NFS 文件服务 (nfs v3)。我们正在共享一条路径以进行匿名读/写访问。

我们有一台 Linux 主机，我们希望挂载导出的读/写共享，并允许在该客户端计算机上匿名读/写访问挂载的共享。不幸的是，最终发生的结果是 root 可以写入共享，但非特权用户不能。

使用以下方法挂载共享：

# mount -t nfs -o rw 10:10:xx:xx:/path/to/share /mnt/mounted_path
# mount -t nfs -o rw,users 10:10:xx:xx:/path/to/share /mnt/mounted_path
# mount.nfs 10:10:xx:xx:/path/to/share /mnt/mounted_path -o rw

我们有特定的用户打算用于共享上的匿名使用。因此，我尝试以该用户身份挂载该卷：

# su - shared_user
$ sudo mount.nfs 10:10:xx:xx:/path/to/share /mnt/mounted_path -w -o user=shared_user,rw
mount.nfs: an incorrect mount option was specified

去读了一些书：http://nfs.sourceforge.net/nfs-howto/ar01s06.html。

决定尝试以下操作，但在尝试挂载时会出现以下错误：

# mount -t nfs -orw,no_root_squash 10:10:xx:xx:/path/to/share /mnt/mounted_path 
mount.nfs: an incorrect mount option was specified
# mount -t nfs -orw,nroot_squash 10:10:xx:xx:/path/to/share /mnt/mounted_path  # for grins and giggles.
mount.nfs: an incorrect mount option was specified
$ sudo mount.nfs 10:10:xx:xx:/path/to/share /mnt/mounted_path -w -o user=shared_user,rw,no_root_squash
mount.nfs: an incorrect mount option was specified

我只是在 SOL 还是我根本忽略了什么？这是我试图寻找的圣杯吗？我从未大量使用过 NFS，所以我现在有点不知所措。TIA！

答案1

好的。搞定了。首先，我使用的 Nexenta 版本是 3.1.3.5。Nexenta 是一款基于 OpenSolaris 的设备，可通过 CIFS、NFS、Rsync、WebDAV 和 FTP 提供块存储。在我们的例子中，我们仅将其用于 NFS（v3 是默认版本。此版本不提供 v4）。

因此，就 Nexenta 而言，tl;dr; 如下：

以 root 身份登录 Nexenta：

$ ssh [email protected]
Password:
Last login: Wed Aug 24 11:17:33 2016 from xx.xx.xx.xx
nmc@nex01:/$ option expert_mode = 1

nmc@nex01:/$ !bash
You are about to enter the Unix ("raw") shell and execute low-level Unix command(s). Warning: using low-level Unix commands is not recommended! Execute?  Yes

root@nex01:/volumes#
root@nex01:/volumes# grep nfs /etc/passwd
nfs:x:60001:60001:NFS Anonymous Access User:/:/bin/sh

注意第一个数字之后的数字x:#####:#####- 这些分别是 uid 和 gid。

在客户端：创建用户：

# groupadd nfs -g 60001 && useradd nfs -g 60001  ## untested. I did it the long way through natural process of elimination, so be careful here.

现在一切都好了。

挂载该卷并验证新创建的 nfs 用户是否可以写入 NFS 卷。

长版本：

据我所知，我已经正确设置了 NFS 端。文档很有帮助，但在某些方面，它只是在提供一些帮助。

“允许匿名访问此共享。共享顶级目录将被授予匿名用户‘nfs’的读写访问权限。如果递归共享模式设置为 true，则此属性将传播到现有子文件夹。请注意，匿名读/写访问权限不可继承 - 除非明确请求，否则不允许匿名访问未来的子文件夹。匿名用户名是‘nfs’。”

我的shared_user最终变成了“nfs”，但仍然失败了（见 OP）。我决定，因为我认为这不太可能，让我在客户端的 UID 与设备上“nfs”的 UID 相匹配。我必须登录到设备，启动 bash shell，然后运行命令id来获取 UID，在我的情况下是 60001。

在客户端上，我更改了nfs用户以匹配设备上的 UID。显然，设备确实需要 UID/GID 与其自身相匹配才能正常工作。我认为 NFS 服务器会忽略这一点。这显然是问题的关键。

现在，设备使用 nfs:nobody 作为 user:group。nobody在客户端 (Linux) 端有一个不同的 UID，更改 nobody 的 UID 会稍微复杂一些，我不知道更改该 groupid 会无意中产生什么影响，所以我没有动它。nfs在我开始乱搞之前，客户端计算机上的用户是不存在的，因此不存在破坏任何东西的风险。客户端有一个nfsnobody。我没有测试使用它，而且我很确定它不会起作用，因为文档中对用户 ID 有具体说明。

我还应该在此说明，该设备专门设置为使用 sysauth 进行身份验证。使用 auth=none 不是一个选项，因为 NFSv3 似乎不喜欢它。:)

就这些。

相关内容