fnOS /vol1 权限被锁 000 事件记录

文档日期：2026-08-30 涉及设备：部署机 fnos（192.168.31.225，跑 k3s + docker 全家桶）

---

一、现象

• /vol1 挂载点及其下 k3s、thumb、vm、1000(admin 用户目录)、lost+found 等顶层目录权限位全部变成 000（d---------），连 root 之外的用户都进不去
• k3s 集群节点 NotReady：kubelet 无法启动，14 个服务全部调度失败（Pending / Terminating）
• 首次发现后手动 chmod 修复 + 重启 k3s 可恢复，但再次重启 fnOS 后 /vol1 根目录又被锁回 000

二、排查结论

谁引起的 —— fnOS 官方已确认的已知内核 Bug

官方技术团队定位（飞牛私有云论坛）：

曾经操作（如手动执行 umount / docker build / docker compose 部署），把一些系统文件路径挂载到了其他存储路径， 内核会以为原路径被卸载了，触发特殊权限处理，导致没有权限访问系统文件路径。

触发链：执行容器类操作（docker build / compose / k3s 调度）→ 触发 umount 冲突 → fnOS 内核误判 → 特殊权限处理把目录权限置 0。

官方口径：

• 只影响权限，不影响数据
• 重启通常能恢复（偶发，不是每次都复现）
• 官方在后续系统更新中会修复（更新内核策略）
• 着急可联系飞牛官方私发设备 ID 领内测包

与本次情况的吻合点

• 触发时正值 k3s + docker 体系运行（与我们看到的容器调度、FailedCreatePodContainer 事件吻合）
• 现象与论坛多个帖子完全一致（docker 部署后文件夹权限全部失效/变 000）
• 重启能恢复的官方说法，与我们重启后恢复的事实一致

排除项

• k3s 自身无问题（权限修好后再没复发）
• 非用户 & 非普通应用的误操作
• 非磁盘/文件系统损坏

三、修复方案（已部署）

3.1 手动修复（临时，命令）

chmod 755 /vol1
chmod 750 /vol1/1000
chmod 755 /vol1/k3s /vol1/thumb /vol1/vm
chmod 700 /vol1/lost+found

3.2 开机自动修复（已部署到 fnos，推荐长期方案）

脚本 + systemd 服务，开机在本地文件系统挂载后自动执行，幂等：

• 脚本：/usr/local/bin/fix-vol1-perms.sh
• 服务：fix-vol1-perms.service（已 enable）
• 日志：/var/log/fix-vol1-perms.log

若 /vol1 又变 000，直接跑一遍脚本即可，无需重启：

/usr/local/bin/fix-vol1-perms.sh

3.3 重启验证结果（2026-08-30，实测通过）

检查项	结果
重启后 /vol1 是否被锁	是（日志：修复 /vol1: 0 -> 755），bug 确认复发
修复服务是否开机自动执行	是（Active: exited, status=0/SUCCESS）
修复是否真实生效	是（0 -> 755，时序正确，未被"先修后锁"覆盖）
k3s 节点	Ready
14 个服务	全部 1/1 Running

说明：fnOS 该 bug 为偶发，不一定每次重启都复现；若在运行中（如 docker build 后）复发，可手动跑脚本恢复，或后续加 timer 定期自检兜底。

四、参考链接

• 飞牛论坛贴（官方确认帖）：https://club.fnnas.com/forum.php?mod=viewthread&tid=42361（同问题）
• 官方内测包申请/反馈渠道：飞牛论坛私信「飞牛技术同学」

五、后续建议

1. 关注 fnOS 系统更新，发布修复内核后即可移除临时修复服务（可选）
2. 操作容器/存储路径挂载时，尽量避免手动物理 umount 系统路径
3. 定期巡检：stat -c "%a %n" /vol1，非 755 即触发修复脚本