Docker Rootless 模式允许普通用户运行 Docker 守护进程与容器，可减少守护进程以 root 身份运行带来的安全风险。不过，Rootless 依赖用户命名空间，网络、存储、资源限制和端口映射方式与传统模式存在差异。其中最常见的问题，就是映射 80、443 等低端口时出现“permission denied”或端口无法监听。本文从部署、验证到低端口排查，整理一套可直接执行的流程。🔧
一、理解 Rootless 模式
传统 Docker 通常由系统级 root 守护进程管理；Rootless 模式则把 Docker daemon 和容器都运行在普通用户的用户命名空间中。它不同于 userns-remap：后者仍由具有 root 权限的 daemon 提供服务，而 Rootless 模式连 daemon 本身也不需要 root 权限。具体原理可参考 Docker Rootless 官方文档。
这种模式适合开发机、共享服务器和希望缩小权限边界的环境，但它并不等于“完全免配置”。安装系统软件包、配置 subordinate UID/GID、修改 sysctl 或授予端口绑定能力时，仍可能需要管理员协助。
二、部署前检查
Rootless Docker 需要 newuidmap 和 newgidmap。Debian、Ubuntu 可安装 uidmap 软件包，其他发行版应使用对应的软件包管理器。同时，当前用户需要在 /etc/subuid 和 /etc/subgid 中拥有足够的从属 UID、GID 范围。
which newuidmap
which newgidmap
grep "^$(whoami):" /etc/subuid
grep "^$(whoami):" /etc/subgid
正常记录通常类似“用户名:起始编号:65536”。如果没有输出，应由管理员分配不与其他用户重叠的范围。官方文档建议至少提供 65536 个 subordinate UID/GID。
如果机器原来运行普通 Docker，建议先确认是否需要保留。两个 daemon 可以通过不同套接字并存，但容易出现 CLI 连错环境、容器列表不一致等问题。若决定只使用 Rootless，可由管理员停止系统级 docker.service 和 docker.socket。
三、安装并启动 Rootless Docker
通过 Docker 的 RPM 或 DEB 软件包安装后，通常可直接以普通用户执行：
dockerd-rootless-setuptool.sh install
如果找不到该命令，应检查是否安装 docker-ce-rootless-extras。安装脚本会创建用户级 systemd 服务，并通常建立名为 rootless 的 Docker context。随后启用服务：
systemctl --user enable --now docker
sudo loginctl enable-linger $(whoami)
enable-linger 可让用户退出登录后继续运行用户服务。服务文件一般位于 ~/.config/systemd/user/docker.service，不应把 Rootless Docker 配置成带 User= 参数的系统级服务。相关运行建议可查看 Rootless 使用技巧。
四、确认客户端连接正确
部署成功后，不要急于启动业务，先确认 CLI 是否连接到 Rootless daemon。🧭
docker context ls
docker context use rootless
docker info
在 docker info 输出中，应看到当前上下文和 Rootless 相关安全信息。如果 docker ps 显示的容器与预期不符，优先检查 docker context show、DOCKER_HOST 和套接字路径。Rootless 套接字通常位于 /run/user/当前UID/docker.sock，而传统 Docker 常使用 /var/run/docker.sock。
接着使用高端口验证基础网络：
docker run --rm -d --name rootless-web -p 8080:80 nginx
curl 来源链接
如果 8080 可以访问，说明镜像、容器服务和端口转发链路基本正常；此时 80 或 443 失败，通常就是宿主机低端口权限问题。
五、为什么低端口绑定失败
Linux 默认把低于 1024 的端口视为特权端口，普通用户进程不能直接绑定。Rootless Docker 的端口转发由 RootlessKit 等用户态组件完成，因此执行“docker run -p 80:80”时，真正尝试监听宿主机 80 端口的是非 root 进程，系统可能返回权限错误。
需要注意，容器内部监听 80 并不是问题。命令中的前一个端口属于宿主机，后一个端口属于容器。例如 -p 8080:80 可以成功，而 -p 80:80 失败，差异就在宿主机监听端口。
六、低端口问题的三种处理方案
方案一：使用高端口配合反向代理
这是更容易控制权限边界的方式。让 Rootless 容器映射到 8080、8443，再由宿主机上的 Nginx、HAProxy、Caddy 或负载均衡器监听 80、443 并转发请求。✅
- 容器保持普通用户权限，不修改系统低端口策略。
- TLS 证书、访问日志和限流可集中管理。
- 适合生产环境、多应用共用入口和已有网关的场景。
方案二：为 RootlessKit 授予绑定能力
Docker 官方给出的方式之一，是为实际使用的 rootlesskit 二进制授予 CAP_NET_BIND_SERVICE，然后重启用户级 Docker 服务：
sudo setcap cap_net_bind_service=ep $(which rootlesskit)
systemctl --user restart docker
执行前应确认 which rootlesskit 返回的是当前 Rootless 服务实际调用的文件。软件升级可能替换二进制并清除 capability，因此升级后需要重新检查：
getcap $(which rootlesskit)
这种方案的影响范围比全局降低低端口门槛更小，但仍应纳入安全变更记录。
方案三：调整非特权端口起始值
另一种方法是修改内核参数，例如把 net.ipv4.ip_unprivileged_port_start 设置为 0，使普通用户可绑定全部 TCP/IP 端口：
sudo sysctl net.ipv4.ip_unprivileged_port_start=0
若要持久化，可写入 /etc/sysctl.d/ 下的独立配置文件，再执行 sudo sysctl --system。该设置影响整台主机上的普通用户进程，而不只影响 Docker，因此共享服务器上不宜直接采用；如只需开放部分端口，可根据实际安全策略设置更合适的起始值。
七、按顺序排查端口不可用
- 确认 context：执行 docker context show，排除连接到传统 Docker daemon。
- 检查容器：执行 docker ps 和 docker logs 容器名，确认应用已启动并监听正确地址。
- 检查映射：执行 docker port 容器名，核对宿主机端口与容器端口。
- 检查监听：执行 ss -lntp，确认目标端口是否已被其他服务占用。
- 验证高端口：先测试 -p 8080:80；高端口正常而低端口失败，重点检查 capability 与 sysctl。
- 查看用户服务日志：执行 journalctl --user -u docker --no-pager -n 100，定位 RootlessKit 或端口驱动报错。
- 检查外部访问：本机 curl 正常但远程失败时，再检查防火墙、安全组、监听地址和上游网络策略。
排查时不要只看容器日志。低端口绑定发生在宿主机侧，错误更可能出现在 Docker 用户服务日志中；如果直接反复重建容器，通常不能解决权限问题。⚠️
八、总结
部署 Rootless Docker 的关键，是正确配置 subordinate UID/GID、使用用户级 systemd 服务，并确认 Docker CLI 连接到 rootless context。遇到 80、443 绑定失败时，应先用 8080 等高端口验证链路，再检查端口占用、RootlessKit 权限和内核参数。
生产环境优先考虑“高端口加反向代理”；确需容器直接暴露低端口时，可按风险范围选择为 RootlessKit 添加 CAP_NET_BIND_SERVICE，或调整 net.ipv4.ip_unprivileged_port_start。无论选哪种方式，都应在变更后重新检查监听状态、服务日志和外部访问路径，避免为了便利削弱整台主机的权限边界。🔒
