NFS权限控制核心是服务端/etc/exports配置与客户端UID/GID映射协同：默认root_squash防提权，需配合anonuid/anongid指定映射目标，rw/ro控制读写，sync保数据安全，且必须exportfs -arv重载生效。
处理NFS网络共享目录的权限，核心在于服务端导出控制与客户端用户映射协同配合。单纯改本地目录权限或只设rw选项往往无效，因为NFS的权限判断发生在服务端，且默认不传递用户名，只认UID/GID。
服务端导出配置决定基础访问能力
在 /etc/exports 中，权限由括号内的选项组合控制：
- rw：允许读写；ro：只读，这是最基础的开关
- root_squash（默认）：把客户端的 root 用户映射成服务端的 nobody，防止提权，生产环境必须启用
- no_root_squash：保留客户端 root 权限，仅限可信内网测试用，非常危险
-
anonuid 和 anongid：指定匿名用户（如被 squash 后）映射到服务端哪个 UID/GID，例如
anonuid=1001,anongid=1001，可让所有未认证用户以固定账号操作 - sync：确保写入落盘再返回，避免断电丢数据；async 虽快但不安全，禁用于生产
写完后必须运行 sudo exportfs -arv 刷新，否则配置不生效。注意语法：路径与客户端间无空格，括号紧贴客户端，选项逗号分隔、中间不能有空格。
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
客户端需匹配服务端的UID/GID
NFS不传用户名，只比对数字ID。如果服务端文件属主是 uid=1001，而客户端当前用户是 uid=1000，即使名字都叫“appuser”，也会提示 Permission denied。
- 检查服务端文件归属：
ls -ln /path/to/shared，看实际 UID/GID - 检查客户端运行用户：
id，确认 UID/GID 是否一致 - 不一致时，可在客户端创建同 UID 的用户：
sudo useradd -u 1001 appuser，或启动容器时用--user 1001:1001 - Docker 场景下，挂载时可加选项强制映射：
mount -t nfs -o uid=1001,gid=1001 server:/share /mnt
防火墙与SELinux可能拦截真实权限
即使配置全对，也可能因底层限制失败：
- 防火墙需放行 NFS 关键端口：2049/tcp+udp 是主端口，但
rpcinfo -p server_ip可查 mountd、nlockmgr 等实际使用的高位随机端口；推荐临时停用防火墙验证，或按需开放 - SELinux 默认阻止 NFS 挂载，可临时关闭：
sudo setenforce 0；长期方案是启用布尔值：sudo setsebool -P nfs_export_all_rw on - 服务端若用
no_root_squash，客户端又以 root 挂载，仍可能因 SELinux 上下文受限而无法写入，此时需chcon -t public_content_rw_t /shared/path
常见问题快速定位
挂载成功但无法读写？按顺序排查：
- 服务端执行
showmount -e localhost，确认共享已导出且可见 - 客户端执行
showmount -e server_ip，确认能发现共享目录 - 客户端用
mount | grep nfs查挂载选项，确认是否含ro或缺少rw - 服务端检查文件系统本身权限：
ls -ld /shared，确保至少对 other 或对应组有 r-x（目录）或 rwx（写入时） - 尝试在服务端用
sudo -u nobody touch /shared/test，模拟被 squash 后的操作是否可行
