DEBUG.WIKI
V.PS：让项目靠近用户，亚太、欧洲、北美 KVM VPS
IPPeak：从目标地区访问网页，住宅代理、SEO 监测、广告验证
ZgoCloud：多地区部署，按需选节点；日本、美国、香港、德国

ReadWriteOncePod 卷仍是 root:root，fsGroup 为什么没有生效

CSI 文件系统卷采用 ReadWriteOncePod 和 ReadWriteOnceWithFSType，旧实现可能跳过组权限。核对节点修复、驱动委托及实际目录权限。

5 min
Kubernetes

Pod 设置了 fsGroup，CSI 文件系统卷却仍以 root:root、0755 挂载，非 root 程序写入时报 Permission denied。如果该卷使用 ReadWriteOncePod，而 CSIDriver 的策略是 ReadWriteOnceWithFSType，需要检查节点所用 Kubernetes 实现是否包含对这个访问模式的修复。

旧实现对这种策略只识别 ReadWriteOnce，漏掉了 ReadWriteOncePod，因而可能跳过卷的组权限处理。把 fsGroupChangePolicy 从 OnRootMismatch 改成 Always，不能让这条未满足的处理条件自动成立。

对照实际 PVC、PV、驱动和节点

以下检查只读取对象与权限；命名空间、Pod、PVC、PV、驱动和容器名都要替换：

kubectl get pod web-0 -n team-app -o yaml
kubectl get pvc data-web-0 -n team-app -o yaml
kubectl get pv data-pv -o yaml
kubectl get csidriver ebs.csi.aws.com -o yaml
kubectl get nodes -o wide
kubectl exec web-0 -n team-app -c web -- id
kubectl exec web-0 -n team-app -c web -- ls -ldn /data

从 Pod 的卷引用找到实际 PVC，再按其 volumeName 找到 PV。核对访问模式是否确实是 ReadWriteOncePod、PV 是否为 CSI 文件系统卷、驱动名称和 fsType，以及该驱动对象的 fsGroupPolicy。原始申请清单不一定代表现有卷的全部状态。

接着检查 Pod 层的 securityContext.fsGroup、应用实际用户和附加组，及挂载目录的数字 UID、GID 和模式。交互命令的身份还要与真正的应用进程对照，入口脚本可能切换用户。

fsGroup 处理的是组访问，不是保证文件属主变成 runAsUser。修复后目录仍由 root 拥有，但组和权限允许应用写入，可以是正确结果。只有属主没有改变，并不足以证明失败。

修复进入 1.32，仍需核对具体补丁和驱动路径

这一遗漏在 Kubernetes 1.31.0 的实现中存在，修复已进入 1.32.0；修复后的访问模式判断包含 ReadWriteOncePod。托管集群可能有回补和自己的发布安排，不能据此宣称所有 1.31 补丁都受影响。

这是节点挂载与权限处理相关的路径。核对实际承载 Pod 的 kubelet 版本、云平台修复说明和 CSI 驱动支持，不要只升级控制平面就认为挂载行为已经变化。

另一个需要区分的条件是 CSI 的 VOLUME_MOUNT_GROUP 能力。如果驱动支持并使用组权限委托，fsGroup 由驱动处理，kubelet 不再按同一套逻辑递归更改；此时 CSIDriver.spec.fsGroupPolicy 和 Pod 的 fsGroupChangePolicy 也不控制这一步。Kubernetes 支持委托，不意味着每个安装的驱动都声明了该能力。

驱动策略为 None、缺少适用的文件系统条件、使用原始块设备，以及驱动委托路径中的错误，均不能直接按旧 RWOP 遗漏处理。Secret 卷的组权限处理也不同，密码文件要求更严格时可看 Secret 与 JMX 文件权限。

保留访问模式，通过受支持的升级流程处理

确认属于旧的权限判断路径后，优先按平台支持的方案更新到包含修复、与现有驱动相容的节点版本。变更前保存对象与部署配置、确认卷的数据备份和恢复办法，并安排节点维护、卷卸载及应用中断窗口。

不要直接把已绑定卷的访问模式从 ReadWriteOncePod 改成 ReadWriteOnce 来消除报错。两者的使用约束不同，存储声明也有修改限制；重建存储对象可能影响真实数据和绑定关系。

有些驱动明确支持 fsGroupPolicy: File，但是否采用它，需要依据驱动与平台的正式配置方式评估。它可能扩大递归权限处理范围，影响大卷挂载时间和已有文件权限。不能为了一个 Pod 随手删除、重建整个 CSIDriver，或用宽泛的权限修改替代驱动支持检查。

OnRootMismatch 在根目录条件已经满足时跳过后代的权限调整，是另一种问题。若仅部分旧文件不可写，应读取对应文件和目录的真实权限继续定位，不能把所有 fsGroup 现象都归到访问模式遗漏。

验收组权限和业务写入，而不是只看启动

按维护流程让新实例重新挂载后，核对实际节点版本、目录 GID 与权限、应用进程的组，以及在专用测试路径中的正常业务读写。测试不能覆盖已有文件，确认写入结果和数据内容后再恢复常规负载。

还要观察挂载耗时、权限变化是否符合设计，以及原卷和后端数据是否完整。Pod 启动成功，只能说明启动阶段通过，不能证明应用的每条数据路径都可写。

需要回退节点或驱动配置时，按已保留的兼容方案操作，并重新核对挂载和业务权限。已经发生的文件权限变化不会因版本回退自动撤销；不应对业务卷盲目递归 chown，更不要用 chmod 777 掩盖尚未确认的根因。