podman非特权容器访问宿主文件需同时满足挂载可见性、宿主文件权限、selinux上下文兼容及用户命名空间uid映射匹配；常见报错源于selinux拦截或uid映射不一致，应依次检查上下文（ls -z）、调整（chcon/semanage）、验证uid映射（podman unshare cat /proc/self/uid_map）并显式设置挂载选项（如:rw,rshared）。
Podman 默认以非特权模式运行，容器进程默认无法直接访问宿主文件系统中的文件，尤其当涉及 SELinux、用户命名空间或挂载权限时，常见报错如 Permission denied、No such file or directory（路径存在但不可读）、或进程静默失败。核心原因不是“不能挂载”，而是挂载后**进程无权访问**——需同时满足挂载可见性 + 宿主文件访问权限 + SELinux 上下文兼容性 + 用户命名空间映射匹配。
检查并适配 SELinux 上下文（RHEL/CentOS/Fedora）
SELinux 是最常被忽略的权限拦截点。即使文件属主和 chmod 正确，若上下文类型不匹配（如容器进程需要 container_file_t，而宿主文件是 admin_home_t），访问会被拒绝。
- 查看宿主文件当前上下文：
ls -Z /path/on/host/file - 临时放宽测试（不推荐生产）：
chcon -t container_file_t /path/on/host/file - 永久生效（推荐）：用
semanage fcontext添加规则，再restorecon，例如：sudo semanage fcontext -a -t container_file_t "/opt/myapp(/.*)?"sudo restorecon -Rv /opt/myapp - 若使用
:Z或:z标签挂载（如-v /host:/cont:Z），Podman 会自动重标上下文，但仅对挂载点目录生效，其内部已有文件可能仍保留旧上下文，需手动restorecon。
确认用户命名空间与 UID/GID 映射一致性
启用用户命名空间（Podman 默认开启 rootless）时，容器内 UID 0（root）实际映射为宿主上的非零 UID（如 100000+）。若宿主文件属主不是该映射 UID，且无组/其他权限，容器进程将无权读写。
- 查 rootless 容器实际映射：
podman unshare cat /proc/self/uid_map - 确保宿主文件对映射后的 UID 可访问：可改文件属主（
chown 100000:100000 /host/file），或开放组/其他权限（chmod 644并加入对应组），或在运行时用--user指定容器内 UID 匹配宿主有效 UID。 - 若需容器内真正用 UID 0 操作宿主文件（高风险），可禁用用户命名空间：
podman --userns=keep-id run ...（仅限 rootful）或--userns=host（绕过映射，需谨慎）。
挂载时显式声明访问权限与传播选项
单纯 -v /host:/cont 不保证容器内进程能读写。需明确挂载选项：
- 加
:rw确保可写（默认是ro吗？不，Podman 默认rw，但显式写更安全）； - 对需要同步宿主变更的场景（如日志文件被外部轮转），加
:shared或:rshared避免挂载隔离导致不可见； - 避免使用
:private（默认），它会切断挂载事件传播； - 示例：
podman run -v /home/user/data:/app/data:rw,rshared alpine ls -l /app/data
验证容器内实际访问能力（而非仅路径存在）
别只看 ls 能否列出文件——那是目录权限；要测试进程真实行为：
- 进入容器：
podman exec -it mycontainer sh - 尝试以目标用户身份读取：
su -c 'cat /cont/file' -s /bin/sh $USER（模拟应用用户） - 检查进程有效 UID/GID：
id、cat /proc/1/status | grep -E "Uid|Gid" - 若用 systemd 或其他 init，注意其默认以
root启动服务，但 Podman rootless 下实际是映射 UID，需确认服务配置未硬编码依赖 UID 0。
不复杂但容易忽略。关键在分层排查：先看挂载是否成功（mount | grep cont），再看 SELinux 是否拦（ausearch -m avc -ts recent），接着核对 UID 映射与文件属主，最后确认挂载选项匹配业务需求。四者齐备，权限问题基本解决。
