原理 ：
# NFS 的权限本身没有用户密码和账户验证登录过程
（ 你可以回忆下，我们前面访问远程共享目录的时候，是没有输入账户，密码啥的，是没
有这个步骤的）
所以客户端登录到服务器后，会把客户端的账户身份映射到服务器端
# NFS 要访问成功，不仅与服务器端配置有关，还与操作系统的目录文件权限有关
实验 ：
# 基于上例， 将 nfsfile 目录权限进行修改，查看客户端是否访问成功
[root@server ~]# cat /etc/exports /nfsfile192.168.229.128/24(rw,sync,all_squash) # 上示，我们查看下， NFS 主配置文件里， 查看其 共享权限参数中的权限是怎样的
可以看到， 显示的是 rw ( 即可读可写 ） 权限。
[root@server ~]# cd /nfsfile[root@server nfsfile]# lltotal 4-rw-r--r-- 1 root root 15 Jul 11 00:45 readme-rw-r--r-- 1 nobody nobody 0 Jul 14 23:40 t1.txt# 我们进入到 共享目录 /nfsfile 里， 使用 ll 命令查看 共享文件里 文件系统的权限
显示， 共享目录里的文件 （ readme , t1.txt ） 两个的权限显示都是 rw 权限
即 可读可写；
那就是说，NFS主配置文件（ /etc/exports ）里的 共享权限参数 显示的权限 （ rw ）
和 共享目录（ /nfsfile ） 里的文件（ readme, t1.txt ） 两个文件本身，就它文件自身的
权限（ rw ） 是一样的， 那这就不利于我们做实验了 ；
即 两个权限 是一样的，那就体现不出那个权限是主导的了，所以，我们就做些改变，
把权限改一改， 然后再看权限的改变对最终的影响。
我们所做的这个实验就是为了验证
===>>>
NFS配置的权限在 文件本身的权限 面前是不起作用的，最终是取决于 文件它自己本身
的权限的。
[root@server nfsfile]# chmod -Rf 444 /nfsfile/ [root@server nfsfile]# lltotal 4-r--r--r-- 1 root root 15 Jul 11 00:45 readme-r--r--r-- 1 nobody nobody 0 Jul 14 23:40 t1.txt我们定位到 服务端， 改写 共享目录 里文件 自身的权限，由原来的 rw 改为了 r
那现在，就有个小冲突了，就是权限不一样了 （ 这就是 我们要实验验证所创造的条件 ）
我们不是刚才把 服务端的共享目录的文件权限改成了 r-- （ 只能读，不能写 ）
然后，我们 NFS主配置文件里的 共享权限参数 里的权限是 rw （ 可读 可写 ）
验证 :
我们再定位到 客户端
[root@node1 ~]# cd /nfsfile_khd/-bash: cd: /nfsfile_khd/: Permission denied那么，现在，我们在客户端这边，想要访问 自己的挂载目录，但却发现 没有权限了
已经进不去了，因为没有 写 的权限了 （ 我们上一步不是 把 共享目录里的文件的权限改
了嘛，从 rw 改成 r ）
这就证明了，即使 NFS 主配置文件里的共享权限参数 即使是 （ rw ） 可读可写，但是，还
是取决于 共享目录里文件本身的权限（ r- ） 只读 ~！！！！
我们再来验证下
===>>>
[root@server ~]# chmod -Rf 777 /nfsfile [root@node1 ~]# cd /nfsfile_khd/[root@node1 nfsfile_khd]# lltotal 4-rwxrwxrwx 1 root root 15 Jul 11 00:45 readme-rwxrwxrwx 1 nobody nobody 0 Jul 14 23:40 t1.txt显然，当我们在 服务端 对 共享目录的权限修改成 （ rwx ） 这个时候，客户端就又能访问
远程目录了~！！！！
实验目的 ：
我们所做的这个实验就是为了验证
===>>>
NFS配置的权限在 文件本身的权限 面前是不起作用的，最终是取决于 文件它自己本身
的权限的。
来源地址：https://blog.csdn.net/m0_56332061/article/details/131751309
