主页 / server / 问题 / 798418
Accepted
Jim
Asked: 2016-08-23 10:54:36 +0800 CST

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

  • 772

情况：

我们使用 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，所以现在我有点不知所措。蒂亚！

linux nfs readwrite

1 个回答

  1. Best Answer

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

    所以，tl；博士；在 Nexenta 方面：

    以 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，则此属性将传播到现有子文件夹。请注意，匿名读取/write 访问不可继承 - 除非明确请求，否则不允许匿名访问未来的子文件夹。匿名用户名是 '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，为任何人更改 UID 会涉及更多一点，我不知道通过更改该 groupid 会无意中影响什么，所以我没有碰它。在我开始胡闹之前，客户端机器上的nfs用户是不存在的，所以没有破坏任何东西的风险。客户端有一个nfsnobody。我没有测试使用它，我很确定它不会起作用，因为文档是特定于用户 ID 的。

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

    就这些。

    • 2

相关问题