# NFS 的权限本身没有用户密码和账户验证登录过程
( 你可以回忆下,我们前面访问远程共享目录的时候,是没有输入账户,密码啥的,是没
有这个步骤的)
所以客户端登录到服务器后,会把客户端的账户身份映射到服务器端
# NFS 要访问成功,不仅与服务器端配置有关,还与操作系统的目录文件权限有关
# 基于上例, 将 nfsfile 目录权限进行修改,查看客户端是否访问成功
[root@server ~]# cat /etc/exports
/nfsfile 192.168.229.128/24(rw,sync,all_squash)
# 上示,我们查看下, NFS 主配置文件里, 查看其 共享权限参数中的权限是怎样的
可以看到, 显示的是 rw ( 即可读可写 ) 权限。
[root@server ~]# cd /nfsfile
[root@server nfsfile]# ll
total 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]# ll
total 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]# ll
total 4
-rwxrwxrwx 1 root root 15 Jul 11 00:45 readme
-rwxrwxrwx 1 nobody nobody 0 Jul 14 23:40 t1.txt
显然,当我们在 服务端 对 共享目录的权限修改成 ( rwx ) 这个时候,客户端就又能访问
远程目录了~!!!!
我们所做的这个实验就是为了验证
===>>>
NFS配置的权限在 文件本身的权限 面前是不起作用的,最终是取决于 文件它自己本身
的权限的。