Podman rootless 发布低端口报 permission denied：检查 Linux VM 的权限阈值

Podman 启动容器时，报错包含 rootlessport cannot expose privileged port 和 bind: permission denied，并列出某个低端口以及当前阈值。即使客户端运行在 macOS，容器仍可能由 Podman machine 的 Linux 虚拟机承载，实际绑定端口的环境有自己的权限规则。

这条处理路径针对 rootless 容器发布端口时的权限拒绝。先核对报错中的端口和执行环境；应用支持自定义访问端口时，可以改用允许的高端口。不要把所有 permission denied 都归到同一个 sysctl，也不要直接用更高权限启动另一套容器。

找到真正执行绑定的环境

Linux 的 net.ipv4.ip_unprivileged_port_start 表示相应网络命名空间中第一个非特权端口。低于该值的端口，需要相应的 root 身份或 CAP_NET_BIND_SERVICE 权限才能绑定。内核文档的默认值是 1024，但发行版、虚拟机镜像或管理员可以调整，实际报错和查询值更有判断意义。

在本机 Linux 直接运行 rootless Podman 时，检查该 Linux 环境。使用 Podman machine 时，应检查运行容器的那台 VM，而非只查看 macOS 的网络规则。以下是只读诊断示例：

# 直接运行 Podman 的 Linux 环境
sysctl net.ipv4.ip_unprivileged_port_start

# 使用 Podman machine 时，替换 myvm 为实际机器名
podman machine ssh myvm sysctl net.ipv4.ip_unprivileged_port_start

同时核对客户端当前使用的连接与实际机器。远程连接到其他 Linux 服务端时，本机默认 VM 的值也不能代表那个服务端。如果报错是 address already in use，则应查端口占用；如果容器已经启动但连不上，应继续检查监听地址、协议与映射，这些都不是同一次低端口权限拒绝。

容器内的 root 不等于 rootless 容器在主机网络环境中拥有 root 权限。给容器使用 --privileged 也不能使它超过启动用户本来具有的权限，不应作为端口发布失败的常规修复。

客户端允许改端口时，保留容器端口

假设 Web 服务确实监听容器内 TCP 80，而当前绑定环境允许宿主侧使用 8080。可在原部署配置中将发布片段改为：

-p 127.0.0.1:8080:80/tcp

这是启动参数片段示例，保留原镜像、数据挂载、认证和其他参数。左侧 8080 是发布端口，右侧 80 是容器内服务端口；客户端同步访问预期宿主入口的 8080。已有容器需要按部署流程应用新映射，先记录原参数、确认数据持久化与允许的服务中断。

协议也要对应。发布 UDP 服务时显式使用 /udp；只发布 TCP 不能让 UDP 请求抵达。需要对其他机器开放时，还要按预期接口、VM 转发路径和访问控制另行设计，不能为了方便直接省略绑定地址，将入口扩大到全部接口。

有些协议或客户端固定使用标准端口，不能随意改成高端口。此时应使用已经受管理的转发入口，或由管理员评估实际绑定环境的端口权限策略；不能只改映射后声称业务已经恢复。

必须保留低端口时，由管理员限定变更范围

确需调整 ip_unprivileged_port_start 时，先记录实际网络命名空间中的原值及持久配置，由管理流程决定允许的范围。调低阈值会让同一网络命名空间内的其他非特权进程也能绑定新增开放的端口，并不只授权这一个容器。设为 0 会取消该范围内全部特权端口限制，不宜照着错误提示直接套用。

临时内核值与重启后持久值应分别核对。对于 VM，还要确认配置属于实际使用的机器，升级或重建机器时如何保留；无需为了这一项策略删除 Podman machine 或重建数据存储。

修改失败或业务不再需要时，恢复原策略和部署参数。恢复较高阈值后，新启动的低端口发布可能再次失败，因此先协调相关服务，不能把策略回退当成已运行应用的完整回退。切换到 rootful 运行同样会改变容器身份与存储上下文，需要独立迁移方案，不能当成无影响的重试。

完成后核对目标容器的实际发布端口，客户端按正确协议与入口访问，并确认原持久数据仍在。端口绑定成功后若应用认证或健康检查仍失败，继续处理那一层，不再扩大主机端口权限。