Openshift 4部署Spring Boot应用挂载NFS卷权限不足及异常问题排查

你遇到的Stale file handle错误是导致NFS挂载目录访问异常的直接原因。该错误本质是NFS客户端持有的文件句柄在服务端已失效，继而触发后续权限校验异常、目录属性无法读取的问题。

问题根因说明 #

NFSv3是无状态协议，文件/目录的唯一标识为文件句柄。当出现以下情况时会触发句柄失效：

• NFS服务端对应的共享目录被删除/重建、权限被修改、服务端进程重启
• NFS export配置发生变动
• 同一个PV路径被多个客户端同时挂载，出现文件inode信息变更
• 网络抖动导致NFS挂载断开重连

你的场景完全匹配该问题特征：首次挂载成功说明初始获取的句柄有效，几秒后失效说明服务端侧该目录的句柄信息发生了变动，上层工具无法读取目录属性就会显示全问号，继而触发权限不足的报错。

排查步骤 #

• 排查NFS服务端侧状态
  • 登录NFS服务器检查/tm03v06_vol3014目录的权限、属主是否稳定，确认是否有定时任务、其他进程在修改、删除、重建该目录
  • 检查NFS服务运行状态，查看系统日志确认是否有服务重启、配置重载的记录，执行showmount -e确认export配置无变动
  • 确认是否有其他主机、集群同时挂载了该NFS路径，且执行了目录修改类操作
• 排查Openshift集群侧状态
  • 检查该PV是否被多个PVC绑定、多个Pod同时挂载，确认业务代码是否有删除、重命名/nfs/abc根目录的逻辑
  • 查看Pod所在worker节点的dmesg或/var/log/messages日志，搜索NFS相关报错，确认是否存在网络抖动导致挂载重连的情况
  • 确认PVC绑定状态稳定，无自动解绑重绑定的情况

解决方案 #

临时恢复 #

若要快速恢复业务，直接删除异常Pod触发重建即可；也可在Pod所在worker节点执行umount -l <对应PV的节点挂载路径>，K8s会自动重新挂载恢复访问。

永久修复 #

1. 优化NFS挂载参数，在PV的mountOptions中添加noresvport参数，避免NFS重连时端口变化导致句柄失效，调整后配置如下：

mountOptions:
  - hard
  - nfsvers=3
  - noresvport
  - nolock # 无多客户端文件锁需求时可添加，降低锁冲突概率

2. 对齐用户权限配置：你Dockerfile中创建的technical用户gid为48760，但Deployment的securityContext中runAsGroup和supplementalGroups使用的是44337，建议统一为同一个gid；同时在NFS服务端将共享目录的属组设置为该gid，权限设置为2770，保证同组用户有稳定的读写权限
3. 条件允许的话升级到NFSv4，相比NFSv3有更完善的状态保持机制，可大幅降低Stale file handle的出现概率
4. 清理NFS服务端侧对共享目录的非业务操作，禁止其他进程修改、删除共享目录根路径
5. 若多Pod共享该PV，确保业务代码不会删除、重命名挂载的根目录/nfs/abc

内容的提问来源于stack exchange，提问作者Syed Iftekharuddin