本文章主要针对以下两种场景进行分析
- 本地挂载
- NFS挂载
本地挂载
结论：挂载的文件的用户权限，在容器内部看到的uid、gid及操作权限，与宿主机上看到的一致
宿主机新建挂载目录：
宿主机查看权限
拉起docker镜像，并把宿主机目录挂载到容器中
docker run -d --rm --name busybox -v /root/test:/tmp/ busybox sleep infinity
查看容器内文件目录权限
一定要确保容器执行者的权限和挂载数据卷对应，如果挂载了root的文件到容器内部，而容器内部执行uid不是0，则报错没有权限
NFS挂载
服务端：
NFS服务端共享文件权限
owner的uid及gid
容器内：
NFS挂载到tmp
结论：挂载的文件的用户权限，在容器内部看到的uid、gid及操作权限，与NFS服务端上看到的一致。
但是容器中的用户身份对于NFS服务端来说，需要根据NFS的配置文件进行判断：
- root_squash：默认选项，当客户端使用的是root用户时，则映射到NFS服务器的用户为NFS的匿名用户（nfsnobody）。
- no_root_squash：当客户端使用的是root用户时，则映射到FNS服务器的用户依然为root用户。
- all_squash：默认选项，将所有访问NFS服务器的客户端的用户都映射为匿名用户，不管客户端使用的是什么用户。
- no_all_squash：当客户端使用的用户的uid和gid在服务器端中也存在一致uid和gid的用户时，则映射到NFS服务器的用户为对应用户，其他用户则映射为匿名用户
- anonuid：设置映射到本地的匿名用户的UID
- anongid：设置映射到本地的匿名用户的GID
举例：
假设服务器端共享文件夹的访问权限
服务端NFS配置：
no_root_squash,no_all_squash
存在以下几种情况：
- 客户端当前用户为root（uid=0，gid=0），正常读写；
- 客户端当前用户为test（uid=1001，gid=1001），映射成服务端的test，正常读写；
- 客户端当前用户为user1（uid=1001，gid=1001），映射成服务端的test，正常读写；
- 客户端当前用户为rancher（uid=1000，gid=1000），映射成服务端的rancher，只能读不能写；
- 客户端当前用户为user2（uid=2000，gid=2000），映射成服务端的nfsnobody，只能读不能写
no_root_squash,no_all_squash,anonuid=1001,anongid=1001
- 客户端当前用户为root（uid=0，gid=0），正常读写；
- 客户端当前用户为test（uid=1001，gid=1001），映射成服务端的test，正常读写；
- 客户端当前用户为user1（uid=1001，gid=1001），映射成服务端的test，正常读写；
- 客户端当前用户为rancher（uid=1000，gid=1000），映射成服务端的rancher，只能读不能写；
- 客户端当前用户为user2（uid=2000，gid=2000），映射成服务端的nfsnobody（uid=1001，gid=1001），正常读写
root_squash,all_squash
只有1种情况：不管客户端当前用户是什么，均映射成服务端的nfsnobody，只能读不能写
