情况：
我们使用Nexenta设备进行NFS文件服务（nfs v3）。 我们正在共享匿名读/写访问的path。
我们有一个Linux主机，我们希望装载该导出的读/写共享，并允许匿名读/写访问该客户机上的已装载的共享。 不幸的是，最终发生的事情是根可以写入共享，但非特权用户不能。
使用以下方法安装共享：
# 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还是有什么我在这里从根本上失踪？ 这是我试图find的圣杯？ 我从来没有大量使用NFS，所以现在我在这里有一些损失。 TIA！
好。 弄清楚了。 首先，我使用的Nexenta版本是3.1.3.5。 Nexenta是一款基于OpenSolaris的设备，通过CIFS，NFS，Rsync，WebDAV和FTP提供块存储。 在我们的例子中，我们只用于NFS（v3是默认的，v4不适用于这个版本）。
所以，tl; dr; 在Nexenta方面：
以root身份loginNexenta：
$ 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:#####:#####之后的数字x:#####:##### – 这些分别是uid和gid。
在客户端：创build用户：
# groupadd nfs -g 60001 && useradd nfs -g 60001 ## untested. I did it the long way through natural process of elimination, so be careful here.
现在一切都好。
安装卷并确认您新创build的nfs用户可以写入NFS卷。
长版本：
就我所知，我已经正确地设置了NFS端。 该文件是有帮助的，但在某些方面，它只是分裂面包屑。
“允许匿名访问此共享共享顶级目录将被授予对匿名用户'nfs'的读写访问权限，如果将recursion共享模式设置为true，则将此属性传播到现有的子文件夹。 /写访问是不可inheritance的 – 匿名访问未来的子文件夹将不被允许，直到明确要求。匿名用户名是“nfs”。
我的shared_user最终成为“nfs”，但仍然失败（请参阅OP）。 我决定，因为我认为这是一个长远的目标，使我的客户端上的UID匹配设备上的'nfs'的UID。 我必须login到设备，启动一个bash shell，然后运行id命令来获取UID，在我的情况下是60001。
在客户端上，我更改了nfs用户以匹配设备上的UID。 显然，设备确实需要UID / GID来匹配它自己的工作。 我想NFS服务器会忽略这一点。 这显然是问题的关键。
现在，设备使用nfs：nobody作为用户：组。 客户端（Linux）上的nobody都是不同的UID，更改UID对于任何人都会有点牵扯，我不知道我可以通过更改该groupid而无意中影响到，所以我没有碰它。 客户机上的nfs用户在我开始使用之前是不存在的，所以没有任何破坏的风险。 客户端有一个nfsnobody 。 我没有testing使用它，我敢肯定，它不会工作，因为文档是特定于用户ID。
我还应该在这里说明该设备是专门设置为使用sysauth进行身份validation的。 使用auth = none不是一个选项，因为NFSv3似乎不喜欢它。 🙂
就这些。