怎么在 Linux 上跑 Podman 6.1 无 root 容器

Podman 当年就是那个”不需要守护进程”的 Docker 替代品,但到了 6.x 系列,它已经不再是猎奇选项,而是 2026 年在 Linux 上跑容器最合理的默认选择。2026 年 7 月发布的 6.0 带来了实质性的安全修复、重写的网络栈,以及整个项目迁入新的 CNCF 所属 GitHub 组织。之后的 6.1.x 补丁版本补上了大家真正想要的一些便捷命令,比如 podman volume rename 和 podman machine restart。

本文将带你安装 Podman 6.1、以普通用户身份跑起第一个容器、理清 6.0 到底改了什么,以及从 Podman 4/5 升级时最容易踩的坑。

官方项目主页:https://podman.io/

Podman 容器管理界面。截图来自 Podman 官方项目。

为什么现在要关注 Podman 6

2026 年发生了两件事,让这个话题变得应时,而不是又一篇”又一个容器工具”的文章。

第一,Podman 6.0.0 于 2026 年 7 月 2 日发布,并且在同一个版本里修复了两个 CVE:

• CVE-2026-57231 —— 使用畸形 Env 条目的恶意镜像,可能导致宿主机的环境变量泄漏到由该镜像创建的容器中;其中的 * 通配符甚至可以在不知道具体变量名的情况下批量泄漏大量环境变量。
• CVE-2026-19730 —— podman quadlet install --replace 在替换文件时没有截断原文件,用短文件替换长文件会残留旧内容。

如果你在 CI、构建服务器上跑 Podman 5.x,或者会从不完全可控的镜像仓库拉取镜像,这个升级应该尽快做。

第二,项目治理结构变了。随 6.0 发布,Podman、Buildah、Skopeo 迁入了新的 CNCF 所属 GitHub 组织 github.com/podman-container-tools。旧的 github.com/containers 仓库会重定向,但导入路径也变了:Go 模块路径现在是 go.podman.io/podman/v6,不再是 github.com/containers/podman/v5。如果你有代码直接引用 Podman 的 Go 库,这是不改就编译不过的破坏性变更。

截至本文撰写时,最新稳定版是 v6.1.4,发布于 2026 年 10 月 12 日。

安装 Podman 6.1

Podman 基本覆盖了所有主流发行版,大多数情况下包名就叫 podman:

# Debian / Ubuntu
sudo apt-get update
sudo apt-get -y install podman

# Fedora
sudo dnf -y install podman

# Arch Linux / Manjaro
sudo pacman -S podman

# Alpine
sudo apk add podman

# openSUSE
sudo zypper install podman

# Gentoo
sudo emerge app-containers/podman

在 Debian 13(trixie)和 Fedora 上,podman 就在官方基础仓库里,不需要第三方源,也不需要 Docker 那种安装脚本。这在日常开发机上就是 Podman 相对 Docker Engine 的一个实打实的优势。

Fedora 和 RHEL 上有一处需要注意:rootless 网络栈变了,slirp4netns 不再是默认方案,现代替代品是 passt,在 Podman 里体现为 pasta 这个二进制。如果有旧容器依赖 slirp4netns,请显式安装以免出问题:

sudo dnf -y install slirp4netns

想尝鲜 Fedora 的开发版,updates-testing 仓库会领先于稳定通道:

sudo dnf update --refresh --enablerepo=updates-testing podman

跑起第一个无 root 容器

这是 Podman 真正不一样的地方,建议亲手敲一遍,而不是照抄。

核心思路是:运行容器不需要 sudo。Podman 被设计为以你的普通用户身份无 root 运行。无 root 模式下,它会创建一个用户命名空间,你在容器内部是 root,但在宿主机上你始终是那个没有特权的普通用户。这正是整个设计的目的所在 —— 就算容器逃逸了,攻击者拿到的也不是宿主机 root。

下面是 Debian 13 上以普通用户身份运行的真实会话:

Debian 13 上真实的无 root Podman 会话。终端真实截图,不是模拟图。

关键那行是 rootless=true。随时可以用下面的命令自查:

podman info --format '{{.Host.Security.Rootless}}'

日常用法和 Docker 基本一致:

# 拉取镜像
podman pull ghcr.io/linuxcontainers/alpine:latest

# 跑一个一次性容器
podman run --rm alpine echo "hello"

# 查看现有资源
podman images
podman ps -a

# 清理
podman system prune

一个实用提示:podman run 不加 --rm 时容器退出后仍然保留,这一点常让从 Docker 迁过来的人意外。想要 Docker 那种自动清理行为,就用 --rm,或者直接设个别名:

alias docker=podman

这个别名出奇地好用。绝大多数 Docker 命令可以一一对应,这也正是 Podman 兼容层最不显山不露水却最有价值的地方。

Podman 6 到底改了什么

Podman 6 不是一个”主打新功能”的版本,而是一个清理版本,而这个清理带来了实实在在的破坏性变更。如果你正从 5.x 升级,下面这份清单才是真正要看的。

网络栈被整体替换。 Podman 6 完全移除了 slirp4netns、iptables 和 CNI 支持,网络现在走 Netavark、Aardvark 和 Pasta 配合 nftables。只在 slirp4netns 下有意义的 --network-cmd-path 全局选项也被删除。这大概是整个版本最大的变化 —— 如果你有自定义的 CNI 网络配置,在迁移到 Netavark 网络定义之前它们无法工作。

老平台被放弃。 Intel Mac、Windows 10 以及 cgroups v1 系统不再支持。Podman 6 要求 cgroups v2,意味着内核相当新 —— 实际门槛大约是 5.8 或更新。如果你还在老内核或遗留企业主机上,Podman 5.8 是最后一个支持你的版本。

存储现代化。 BoltDB 数据库支持被移除,Podman 6 首次运行时会自动把 BoltDB 数据库迁移到 SQLite。同时新增的 --import-native-ca 标志会从宿主机原生证书库读取受信任的 CA 证书并同步进 Podman machine 客户机 —— 对身处企业 TLS 中间人代理环境的人是个非常实用的修复,过去这需要手动导出并注入证书。

Quadlet 被重构。 Quadlet 及其关联文件现在放进子目录,不再靠单个 .app 文件追踪。这意味着删除一个 Quadlet 不再连带删除所有非 Quadlet 的关联文件,少了一整类”我的 systemd unit 不见了”的 bug。podman quadlet install --replace 也修好了目标文件截断问题 —— 这正是 CVE-2026-19730 的来源。

Quadlet 新增 REST API,改进了关联文件追踪,扩展了 .volume 单元支持,并为发行版打包增加了额外搜索路径。

6.1 里值得知道的新增

6.1.x 系列才是各种小便捷落地的地方。来自官方 6.1.0 公告:

• podman volume rename —— 原地重命名卷,不用再建一个再拷数据。使用了外部卷驱动、或正被运行中容器挂载的卷暂时还不能改名。
• podman machine restart —— 一条命令重启 Podman 托管的虚拟机,不用再串 stop 和 start。
• podman network rm --ignore —— 删除不存在的网络时不再报错,清理脚本终于可以做到幂等。
• podman manifest push --retry / --retry-delay —— manifest 推送自动重试,镜像仓库偶发抖动时不必自己写重试循环。
• podman generate kube 现在会把容器健康检查映射为 Kubernetes 的 livenessProbe,生成的 YAML 更忠实于原容器。
• WSL 在 containers.conf 中新增 force_port_listen 选项,Podman 现在会在新建 WSL provider 虚拟机时自动设置,让 Windows 宿主机的端口转发正常工作。
• 新增的 Pasta 转发模式经过重构,IPv6 端口转发现已正确工作。
• podman info 现在会连同已用和总量一起报告空闲内存。

另外官方还有一篇专门讲无 root Podman 保留源 IP 的博客文章,如果你把容器放在代理后面、需要真实客户端地址而非 NAT 地址,值得一读。

Podman machine、Podman Desktop 与 Windows

在 macOS 或 Windows 上用 Podman,你并不是原生跑容器 —— 容器跑在 podman machine 管理的轻量虚拟机里。

podman machine init
podman machine start
podman machine os update    # 6.0 新增
podman info                 # 验证安装

Podman 6 新增了 podman machine os update 来保持这些虚拟机镜像为最新,并改进了多 provider 体验,在 WSL、Hyper-V 和 Apple Virtualization 之间切换不再那么痛苦。

Windows 安装方式在 Podman 6 中变化很大。 需要管理员权限的老 .exe 安装包没了,换成了单一的双用途 .msi。核心变化是按用户安装:Podman 装进当前用户自己的目录,使用 HKCU 注册表而不是 HKLM,因此在企业受管机器上,没有权限的普通用户也能自行安装。按机器安装仍受支持,但按用户已是默认。从旧安装包升级需要先卸载,因为两者的安装路径根本不同。

在 macOS 上请注意,Podman 6 移除了 Intel Mac 支持,Apple Silicon 继续支持。

Podman Desktop 1.30,Podman 命令行工具的图形化搭档。官方宣传图。

如果你更习惯图形界面,Podman Desktop 是另一个独立项目,目前版本 1.30,提供容器列表、扩展商店和 Kubernetes 支持:

Podman Desktop。官方品牌图。

从 Podman 5 安全升级

按顺序列一份速查清单:

1. 整个 container-tools 栈一起升级。 Podman 6 要求 Buildah v1.44.0、Skopeo v1.23、Netavark 与 Aardvark v2.0.0,以及来自 container-libs v0.68.0 的公共配置文件。把 Podman 6 的二进制和旧版 Buildah 混用,会引发正是你该避开的那种莫名其妙的故障。
2. 在 Linux 上重建 podman machine 虚拟机。 6.0 改变了虚拟机挂载宿主卷的方式(改用 systemd),这一改动导致已有 Linux podman machine 虚拟机上的卷挂载失效。请重建虚拟机。
3. 升级前先把 CNI 网络配置迁移到 Netavark,而不是升级后再补。
4. 检查内核版本。 cgroups v2 现在是硬性要求。
5. 重新构建并推送所有把 Podman 当库嵌入的项目。 Go 导入路径已变为 go.podman.io/podman/v6。

生产环境请锁定到最新的 6.1.x 补丁版本而不是追主版本号,因为 Podman 会在补丁版本里发安全修复 —— 6.1.4 一个版本就修了 WSL 3 兼容性问题、把 gvproxy 升到 v0.9.0 以修复 CVE-2026-107935,并把 Buildah 提升到 v1.45.2。

简短总结

2026 年的 Podman 早已不只是”有意思的替代品” —— 对很多 Linux 环境来说,它就是更好的默认选择。它从基础仓库直接安装、不需要守护进程、不需要 sudo,而且 Docker 兼容层意味着绝大多数现有命令和 compose 文件开箱即用。

6.x 系列让这个理由更强,而不是更弱:网络栈在现代原语上重建,治理权移交 CNCF,还修掉了两个真实存在的 CVE。如果你还在 Podman 4 或 5,这就是该迁移过去的版本 —— 但请先读一遍破坏性变更清单,因为移除 slirp4netns 和 CNI 这件事绝非表面文章。

官方文档与发布说明见 https://podman.io/docs/ 以及项目的 GitHub Releases 页面。