如何获得对Synology NAS的NFS共享的读写权限？

我仅对已装入的NFS共享具有读取权限。

通过在NAS上设置“无压缩映射”，Ubuntu普通用户Permission denied在尝试cd进入共享时会获得访问权限，并且只能使用进行读取访问sudo。
使用squash“将所有用户映射到管理员”设置，客户端普通用户可以cd进入共享并且仅具有对该共享的读取权限。使用sudo不允许写。

Synology NAS：
DS214> id username
uid=1026(username) gid=100(users) groups=100(users),101(administration)

没有南瓜（没有映射）
DS214> cat /etc/exports
/volume1/Files 10.1.1.2(rw,async,no_wdelay,no_root_squash,insecure_locks,sec=sys,anonuid=1025,anongid=100)

所有壁球（将所有用户映射到管理员）
DS214> cat /etc/exports
/volume1/Files 10.1.1.2(rw,async,no_wdelay,all_squash,insecure_locks,sec=sys,anonuid=1024,anongid=100)

Ubuntu客户端：
$ cat /etc/fstab
10.1.1.214:/volume1/Files /mnt/nfs/Files nfs rw,user,auto 0 0

$ id username
uid=1000 gid=1000(username) groups=1000(username), <etc>

$ ls -n /mnt/nfs
drwxrwxrwx 9 0 0 4096 Sep 25 01:28 Files

$ ls -n /mnt/nfs/Files
drwxr-xr-x 11 1026 100 4096 Sep 24 22:05 Data

（我最初错误地指出，使用sudo启用的写访问权限）我可以使用来打开已挂载的NFS共享中的文件，sudo vi /mnt/nfs/Files/Data/test.file但是即使使用也不可以将更改写入文件中sudo。:w!命令中出现vi错误消息是：
"test.file" E212: Can't open file for writing

— 马西利亚
source

NFS根据用户ID（UID）检查访问权限。本地计算机上用户的UID必须与您尝试在服务器上访问的文件的所有者的UID相匹配。转到服务器，然后查看文件权限。id username它们属于哪个UID（找到），并设置了哪些权限？

— Nephente

您能否cd以普通用户身份登上坐骑？如果是，我建议如下。要确认或反驳我的怀疑，请执行以下操作：在客户端cd上将其装入并执行ls -n。这将列出文件所有者和组及其各自的ID。sudo我猜你将不得不这样做。将输出的一行或两行与id （no sudo！）的输出一起添加到您的问题，如果您甚至不能cd以常规用户的身份附加到安装中，则必须检查要导出的目录的权限服务器。

— Nephente

我不能cd以普通用户的身份进入坐骑。在服务器上使用Squash强制权限可作为授予权限的临时修补程序。研究服务器权限和id username。

— marsilea

谢谢，我认为最好以正确的方式使用nfs而不是仅对Squash强行使用：“将所有用户映射到管理员”在服务器上

— 。–

这取决于。您信任客户和用户吗？如果您不这样做，则NFSv3毕竟不适合，因为具有对客户端的根访问权限的任何人都可以欺骗UID。如果需要正确的身份验证，则最好使用SMB。使用NFSv4进行身份验证需要运行相当复杂的Kerberos。但是，尽管如此，您的输出还是让我感到困惑……我认为挂载点是/mnt/nfs/Files。尽管Files属于root，但允许任何人做任何事情。对于我来说，这没有任何意义，为什么您很难以任何用户身份输入该目录。也许从发布相关行/etc/exports？

— Nephente

Answers:

NFSv2 / 3仅根据UID和GID处理权限。服务器上的文件权限与客户端上的用户ID和组ID相匹配。这就是为什么NFSv <4在用户具有对客户端计算机的根访问权限的环境中设计上不安全的原因。在这种情况下，UID欺骗是微不足道的。

请注意，NFSv4通过Kerberos5提供客户端和用户身份验证。如果需要使用用户名和密码进行身份验证，即使在纯Linux环境中，通常也更容易求助于Samba（SMB / CIFS）而不是设置Kerberos。

为了至少防止root权限升级，NFS共享默认与选项导出root_squash，这将映射所有客户端请求来自何处root (uid=0, gid=0)来anonuid和anongid。可以使用来覆盖此行为no_root_squash，从而授予对导出的根访问权限。

在这里，我们看到了另一个缺点。为了正常运行，NFS基本上要求您在所有计算机上都具有相同的UID / GID。您要访问的文件属于1026并具有755的权限。您在客户端上的用户具有uid=1000。GID都不匹配，因此您仅获得世界权限。因此，没有写访问权限。

要解决此问题，您可以执行以下一项操作：

在NAS上，将文件的所有者更改为1000。您可能需要创建该特定帐户。我不知道这将如何影响其他服务。
将本地用户的UID更改为1026。
由于您是唯一访问服务器上文件的人，因此可以使服务器假装所有请求均来自正确的UID。为此，NFS具有选项all_squash。它告诉服务器将所有请求映射到由指定的匿名用户anonuid,anongid。

将选项添加all_squash,anonuid=1026,anongid=100到中的导出/etc/exports。

但是请务必谨慎，因为这将使任何人都有效地安装了导出文件的所有者！

如果您与不完全信任的人们和他们的客户共享网络，以免破坏您的文件，那么您确实应该研究一种提供身份验证的文件共享方法。我认为，Samba是实现这一目标的最简单方法。

— 内芬
source

我之所以选择NFS，是因为我认为它对于Linux到Linux可能具有优势，因为我希望能够通过rsync备份到Ubuntu客户端上的外部USB驱动器来备份NAS（Synology的DSM系统不提供与USB驱动器的同步）。，同时保留文件所有权和权限信息。完整的答案，并感谢您的指导。

— marsilea

不要showmount -e 10.1.1.214看导出选项。Permission denied错误来自NFS服务器本身。尝试将选项从更改rw,user,auto为defaults。

— 穆罕默德·艾祖丁
source