Podman rootless 容器启动失败怎么查：subuid、subgid 与存储目录边界

Podman 的 rootless 容器启动失败，最常见的入口不是镜像本身，而是当前用户没有可用的 subordinate UID/GID 范围，或者镜像存储落在不适合 user namespace 的文件系统上。先核对 /etc/subuid、/etc/subgid，再确认实际的 graphroot，通常比反复加 sudo 更快定位问题。

记住一条边界：rootless Podman 依赖用户自己的 user namespace 和 subordinate ID；配置正确后，存储仍应优先放在本地文件系统，NFS 等分布式文件系统并不会因为换成 rootless 就自动获得兼容性。

rootless 启动失败，先分清是哪一层

rootless 模式会为普通用户创建 user namespace。容器里的 UID 0 只是该 namespace 里的 root，并不等于宿主机 root；Podman 需要从 /etc/subuid 和 /etc/subgid 取得一段可映射的 UID/GID。Podman 官方文档也明确指出，普通用户创建的容器不会被其他用户看到或管理。

因此可以把问题拆成三层：

• 身份映射层：当前用户是否存在有效的 subuid/subgid 条目。
• 存储层：rootless 的镜像和容器数据是否落在用户可写、且支持 user namespace 的本地路径。
• 运行层：overlay 存储、网络设备或镜像文件属主是否还需要额外能力。

subuid 与 subgid 是容器身份的映射边界

先用当前登录用户名核对两份文件，而不是只看容器内的 id：

whoami
grep "^$(whoami):" /etc/subuid /etc/subgid

正常情况下，两份文件都应能找到当前用户名对应的起始 ID 和范围。例如 devuser:10000:65536 表示从 10000 开始提供 65536 个 subordinate ID。缺少其中一份、用户名拼写不一致，或范围不可用，都可能让 rootless 创建阶段失败。

管理员可以按发行版规范为用户分配范围；Podman 文档给出的示例是使用 usermod --add-subuids 和 usermod --add-subgids，也可以直接维护文件内容：

sudo usermod --add-subuids 10000-75535 USERNAME
sudo usermod --add-subgids 10000-75535 USERNAME

不要把这一步误解成“给用户宿主机 root 权限”。它解决的是 namespace 内外的 UID/GID 映射，权限边界仍由内核 user namespace 和文件系统共同决定。

实际存储路径决定 rootless 能否继续工作

rootless Podman 默认把镜像放在当前用户的 XDG_DATA_HOME 下；没有设置时，通常是用户家目录中的 .local/share/containers/storage。可以先确认环境变量和存储配置，再看目录是否位于本地磁盘：

printf '%s\n' "${XDG_DATA_HOME:-未设置}"
podman info --format '{{.Store.GraphRoot}}'

如果 graphroot 指向 NFS、Lustre、GPFS 等不理解 user namespace 的分布式文件系统，rootless 存储可能无法正常工作。把 graphroot 改到本地非 NFS 路径，通常比给远端目录反复补权限更稳妥；同时确认该路径由当前用户拥有并且有足够空间。

OverlayFS 在较老内核上也可能不适合 rootless。Podman 文档建议安装 fuse-overlayfs，并在已经存在的 storage.conf 中显式设置 mount program：

[storage.options.overlay]
mount_program = "/usr/bin/fuse-overlayfs"

这条配置只解决存储驱动兼容性，不会修复缺少 subuid/subgid 的身份映射错误。

日志现象如何对应到具体修复

提示没有可用 UID/GID 映射

优先回到 /etc/subuid 与 /etc/subgid，核对的是当前用户、两份文件同时存在以及范围格式。修复后重新登录用户会话，再重新创建容器，避免把一次旧的 namespace 状态当作新结果。

提示 overlay 或挂载不支持

确认内核版本、fuse-overlayfs 是否安装，以及 storage.conf 是否覆盖了自动探测。若 graphroot 在 NFS 上，先迁移到本地路径；不要把 NFS 的读写权限问题和 overlay 驱动问题混成一个错误。

容器能启动但文件属主看起来不对

这是 user namespace 映射的可见结果：容器内 UID 与宿主机文件属主不是简单的数字相等关系。若业务必须保持某个 UID，可再评估 --userns=keep-id 等模式，但它会改变映射策略，不能作为所有镜像的默认修复。

一条可复用的核对顺序

1. 记录 whoami，确认两份 subordinate ID 文件中的用户名完全一致。
2. 查看 graphroot，确认它位于当前用户可写的本地存储。
3. 检查 overlay 驱动与 fuse-overlayfs，只在日志指向存储挂载时调整。
4. 最后再排查网络辅助工具；rootless 网络设备缺少 pasta 时，容器可能退回宿主网络 namespace，这与身份映射是另一条链。

顺序的价值在于每次只改变一个边界：先修映射，再修存储，最后处理网络和镜像属主。这样重试得到的结果才有解释空间。

常见误区与安全边界

不要因为容器内显示 root 就把 rootless 容器当成 rootful 容器；不要把整段宿主目录递归改成 777；也不要把根目录下的 rootful Podman 存储直接当作普通用户存储。rootless 容器由创建它的用户隔离管理，切换到 root 执行 Podman 看到的可能是另一套容器和存储。

常见问题

只配置 subuid，不配置 subgid 可以吗？

不建议。Podman 的 rootless 文档要求为用户准备 subordinate UID 和 GID；两份配置不完整时，镜像或文件属主映射可能在创建阶段失败。

为什么换成本地目录后问题消失？

因为 rootless 存储依赖 user namespace 能被底层文件系统正确理解。NFS 等分布式文件系统的限制不会由 Podman 自动消除，本地 graphroot 只是在正确的存储边界内运行。

rootless 容器为什么不能被 root 用户的 Podman 看到？

普通用户和 root 使用不同的用户、namespace 与存储上下文。Podman 官方文档明确说明，普通用户创建的容器不会被其他用户看到或管理。

结语

排查 Podman rootless 的关键不是记住一条万能命令，而是把身份映射、存储文件系统和运行时辅助工具分开验证。先让 subuid/subgid 成立，再让 graphroot 落在兼容的本地路径，最后根据具体日志处理 overlay、网络或镜像属主，问题通常就能收敛到一个可验证的原因。