科技 · 实用指南

systemd 报 status=226/NAMESPACE？关闭加固前先证明失败的命名空间操作

保留首条详细日志错误，把每个命名空间指令映射到真实资源，只修改已证明的边界，不要整体拆掉沙箱。

作者 Watch at Ease News · 2 分钟阅读发布于 2026年10月19日 10:42 UTC

systemd 的 status=226/NAMESPACE 表示在创建挂载、UTS 或 IPC 命名空间时，进程准备阶段失败。服务程序尚未开始正常执行，所以先改应用参数或查应用日志会落在错误层级。

建立四份相互关联的记录：合并后的 unit、首条详细 journal errno、指令到资源的映射、主机或容器边界。只修第一个断点，其余沙箱控制保持启用。

固定有效 unit 与首个失败

保存 systemctl cat 与 systemctl show 的结果，包含 drop-in 和生成属性；记录 systemd、内核、管理器类型及是否位于容器。

从本次启动最早的日志开始读，保留“Failed to set up … namespacing”原行、路径与 errno，不要只记最后的 226 摘要。

逐项列出改变文件系统或命名空间视图的指令，包括 PrivateTmp、ProtectHome、ProtectSystem、路径允许/拒绝、绑定挂载、临时文件系统、根目录/镜像、私有 IPC 与主机名保护。

每项记录源路径、目标路径、预期类型、符号链接解析、供应挂载以及可选“-”前缀的失败语义；不能只看最近改过的一行。

在管理器的主机视图中确认每个源和目标存在且类型正确，用 findmnt 与路径解析区分拼写错误、节点类型错误、缺失挂载和权限拒绝。

EACCES 或 EPERM 要查父目录执行权限、挂载标志与强制访问控制；EINVAL 要先保留失败对象和环境再替换。

Docker、LXC、用户管理器或用户命名空间可能没有完成请求操作所需的命名空间所有权或能力。在测试环境比较最小 unit，不要把生产直接改成特权容器。

记录用户命名空间、内核支持、容器策略及 AppArmor/SELinux 证据；没有拒绝日志不等于内核允许全部命名空间操作。

只纠正已证明的拼写、路径、挂载顺序、节点类型、策略规则或环境限制。若必须放宽沙箱，写明具体冲突，优先使用更窄的绑定或可写路径。

重载并重启，确认原命名空间错误消失、226 不再出现、预期加固仍生效；保存前后 unit、journal 与挂载证据。