Linux - 进阶 NFS 服务器 NFS文件权限与共享目录权限主次问题

linux 运维服务器 2023-09-30 13:09:34 436人浏览八月长安

摘要

原理： # NFS 的权限本身没有用户密码和账户验证登录过程（你可以回忆下，我们前面访问远程共享目录的时候，是没有输入账户，密码啥的，是没有这个步骤的

原理：

# 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 ）这个时候，客户端就又能访问

远程目录了~！！！！