开启Docker用户命名空间映射后，绑定卷chown提示“Operation not permitted”

开启Docker用户命名空间映射后，容器内的root用户会被映射到宿主机的非特权普通用户（默认是dockremap用户/组）。这意味着容器内的root实际上没有宿主机层面的文件修改权限，哪怕添加cap_add: [CHOWN, SETGID, SETUID]也无效——这些能力仅在容器命名空间内生效，宿主机的文件系统权限是硬限制。

以下是几种可行的解决方法：

方法1：调整宿主机绑定目录的所有权匹配映射用户 #

1. 查看Docker用户映射的UID/GID范围：
   打开/etc/subuid和/etc/subgid文件，找到dockremap对应的条目，示例如下：

   dockremap:165536:65536
   

   这里的165536是映射的起始UID，容器内的root（UID 0）会对应宿主机的165536 UID。
2. 修改宿主机绑定目录的所有权：

   chown -R 165536:165536 ./vol/service
   

   执行后，容器内的root用户即可正常修改该目录及内容的所有权。

方法2：临时关闭单个容器的用户命名空间映射（不推荐生产环境） #

如果仅用于临时测试，可在docker-compose.yml中添加userns_mode: host，让目标容器跳过用户命名空间映射：

service_name:
  volumes:
    - ./vol/service:/opt/service:Z
  userns_mode: host
  # 其他配置...

注意：此方法会降低容器的隔离安全性，生产环境谨慎使用。

方法3：使用Docker管理卷替代绑定挂载 #

若无需直接在宿主机操作容器内文件，建议改用Docker管理卷，Docker会自动处理权限适配：

service_name:
  volumes:
    - service_data:/opt/service
  # 其他配置...

volumes:
  service_data:

这种方式下，容器内的root可自由修改卷内文件的所有权，数据由Docker统一管理，安全性和兼容性更好。

内容的提问来源于stack exchange，提问作者Greg Slepak