能跑，但非开箱即用的生产就绪方案；依赖内核≥4.18（推荐≥5.4）、user namespace启用、文件系统支持user_xattr，且需规避cni、volume、存储驱动等rootless特有陷阱。
rootless Podman 在生产环境跑得稳吗？
能跑，但不是“开箱即用”的生产就绪方案。它依赖宿主机内核版本、用户命名空间支持、文件系统权限模型，以及你对“生产”的定义——如果指小规模内部服务、CI/Agent、无状态短期任务，那 rootless 是可行的；如果指高并发、多租户、需 SELinux 精细管控或挂载共享存储的场景，就得谨慎。
哪些 Linux 发行版和内核版本真正支持 rootless 完整功能？
关键看 user.max_user_namespaces 是否启用、内核是否编译了 CONFIG_USER_NS=y，且版本 ≥ 4.18（推荐 ≥ 5.4）。实际踩坑最多的是 CentOS Stream 8 / RHEL 8：默认关闭 user namespace，需手动改 /etc/sysctl.conf 并执行 sysctl -p；Ubuntu 22.04+ 开箱支持，但若用 ext4 且未开启 user_xattr 挂载选项，podman build 会静默失败或镜像层损坏。
- 检查命令：
sysctl user.max_user_namespaces（值应 ≥ 65536） - 验证命名空间：
unshare --user --pid echo ok（非 root 下成功输出 ok 才算基础通过） - ext4 用户需确认挂载参数：
findmnt -t ext4 | grep user_xattr
rootless Podman 启动容器时常见的权限和网络报错
最典型的是 cannot set up network namespace 或 permission denied: opening network namespace——这不是 Podman 问题，而是 rootless CNI 插件没适配当前用户命名空间。默认 podman system service 不启用 rootless CNI，必须显式指定 --network=slirp4netns 或预配置 ~/.config/containers/containers.conf：
[containers] netns="slirp4netns"
另一个高频问题是 volume 挂载失败：permission denied: /home/user/data。这是因为 rootless 容器里进程 UID 映射后无法直接访问宿主目录（尤其当目录属主是其他用户或设置了 strict ACL）。解决方案只有两个：
立即学习“Python免费学习笔记（深入）”；
- 用
--userns=keep-id启动，确保容器内 UID 和宿主一致 - 改用
podman unshare进入用户命名空间后再创建目录：podman unshare mkdir -m 755 /home/user/data
与 Docker rootless 的兼容性差异在哪？
Podman rootless 默认不监听 unix:///run/user/1001/podman/podman.sock，而 Docker rootless 默认走 unix:///home/user/.docker/run/docker.sock。这意味着现有脚本若硬编码了 DOCKER_HOST，不能直接切到 Podman。更隐蔽的问题是镜像构建缓存：Docker rootless 使用 ~/.docker/build-cache，Podman rootless 默认用 ~/.cache/containers，两者不互通，CI 中混用会导致重复拉取和构建变慢。
如果你依赖 buildah 或 podman build --layers 做增量构建，注意 rootless 模式下 overlayfs 不可用，自动 fallback 到 vfs，磁盘占用大、速度慢——这时不如用 podman build --storage-driver=vfs 显式声明，避免行为不一致。
真正麻烦的从来不是“能不能跑”，而是“什么时候它会突然不按你预期的方式跑”。比如 systemd 用户服务中启动 rootless Podman，Delegate=yes 必须设在 unit 文件里，否则 cgroup 权限不足；再比如 NFS 挂载点上运行 rootless 容器，哪怕加了 --userns=keep-id，也可能因服务器端 squash 设置导致 UID 映射失效——这些细节不会报错，只会让日志安静地变少。
