本质是宿主机文件selinux类型与容器策略不匹配，离线可通过semanage+restorecon重置上下文、chcon沿用兼容类型或setsebool临时放宽限制，结合固化规则和挂载前校验预防失效。
bind mount 中因宿主机 selinux 上下文失效导致挂载失败或容器内访问被拒，本质是文件系统标签（type）与容器运行策略不匹配，而非挂载本身出错。这类问题在离线环境（无网络、无法拉取策略模块、audit2allow 无法联网生成规则）尤为棘手，但完全可本地闭环解决。
确认上下文是否真失效
先别急着改策略，用最简命令验证问题根源：
- 查当前挂载点上下文：`ls -Z /host/data` —— 看输出中 type 字段（如 unconfined_u:object_r:user_home_t:s0 或 system_u:object_r:default_t:s0）是否属于容器预期类型（如 container_file_t 或 svirt_sandbox_file_t）
-
查容器进程域：`ps -eZ | grep docker` 或 `docker inspect
| jq '.[0].ProcessLabel'` —— 确认容器实际运行在哪个 SELinux domain（常见为 container_t 或 svirt_lxc_net_t） - 查策略是否允许该 domain 访问该 type：`sesearch -s container_t -t user_home_t -c file -p read | head -1` —— 若无输出，说明当前策略确实拒绝访问
离线修复上下文的三种可靠方式
无需联网、不依赖 audit2allow，全部命令均可在目标机器本地执行：
-
方法一：直接重置为标准容器上下文
适用于挂载目录用途明确（如应用数据、配置、日志）：
`sudo semanage fcontext -a -t container_file_t "/host/data(/.*)?"`
`sudo restorecon -Rv /host/data` -
方法二：沿用已有兼容 type（免策略修改）
若目录原属 var_t 或 etc_t 等基础类型，且容器 domain 已被授权访问（如 container_t 默认可读 var_t），只需确保上下文不被覆盖：
`sudo chcon -R -t var_t /host/data`
再检查 `sesearch -s container_t -t var_t -c dir -p search` 是否有匹配项 -
方法三：临时放宽限制（仅限调试/紧急恢复）
不推荐长期使用，但离线排障时最快见效：
`sudo setsebool -P container_manage_cgroup on`（启用容器管理 cgroup 权限）
`sudo setsebool -P container_use_fusefs on`（若挂载涉及 fuse）
预防下次离线失效的关键操作
SELinux 上下文在某些场景会“丢失”，比如：
• 宿主机重启后未自动重应用 fcontext 规则
• 用 cp/mv 复制文件导致继承源目录 context
• 使用 tar 解压未带 -Z 参数
- 固化规则到文件系统：执行 `sudo semanage fcontext -a -t container_file_t "/host/data(/.*)?"` 后，该规则已写入 `/etc/selinux/targeted/contexts/files/file_contexts.local`，重启不丢失
-
挂载前强制校验：在容器启动脚本中加入：
`[ -d "/host/data" ] && sudo restorecon -Rv /host/data 2>/dev/null || true` - 避免触发重置的操作：复制文件用 `cp -aZ`；解压用 `tar --selinux -xzf`；新建目录后立即 `chcon -t container_file_t /host/data`
