无需启动脚本，如何配置持久化Docker容器卷权限？

问题背景 #

使用Docker Compose挂载配置、日志目录时，容器内始终显示目录所有者为nobody——即便主机已设置与容器用户匹配的UID/GID也无效。出于安全考虑，不愿进入容器修改权限，尝试两种方案均失败：

• 自定义本地卷的bind配置，挂载点未指向指定主机路径
• 直接bind mount并添加:rw参数，容器仍无读写权限

问题复现细节 #

1. 自定义卷driver_opts未更新挂载点 #

docker-compose.yml配置：

services:
  utility:
    container_name: alpine-test
    image: alpine:latest
    volumes:
      - test:/test
    command: sleep infinity

volumes:
  test:
    name: test
    driver: local
    driver_opts:
      type: 'none'
      o: 'bind'
      device: '/opt/dev/fleet-forge/services/test'

执行结果：
运行docker compose up后查看卷信息，发现挂载点仍指向Docker默认存储路径，未绑定到指定主机目录：

$ docker inspect test
[
    {
        "CreatedAt": "2024-06-14T08:21:49-05:00",
        "Driver": "local",
        "Labels": {
            "com.docker.compose.project": "test-mount",
            "com.docker.compose.version": "2.26.1",
            "com.docker.compose.volume": "test"
        },
        "Mountpoint": "/mnt/civpldocker-raid/docker/820896.820896/volumes/test/_data",
        "Name": "test",
        "Options": {
            "device": "/opt/dev/fleet-forge/services/test",
            "o": "bind",
            "type": "none"
        },
        "Scope": "local"
    }
]

主机目标目录权限与内容：

$ pwd
/opt/dev/fleet-forge/services/test
$ ls -alt
total 4
drwxr-sr-x.  2 pstewart dev   40 Jun 14 08:09 .
drwxrwsr-x. 32 pstewart dev 4096 Jun 14 08:09 ..
-rw-r--r--.  1 pstewart dev    0 Jun 14 08:09 testfile1
-rw-r--r--.  1 pstewart dev    0 Jun 14 08:09 testfile2

2. 直接Bind Mount的权限问题 #

docker-compose.yml配置：

services:
  utility:
    container_name: alpine-test
    image: alpine:latest
    volumes:
      - /opt/dev/fleet-forge/services/test:/test:rw
    command: sleep infinity

执行结果：
启动容器后进入内部，目录所有者显示为nobody，且无写入权限：

$ docker exec -it 758c582c2b91 /bin/sh
/ # ls -alt
...
drwxr-sr-x    2 nobody   nobody          40 Jun 14 13:09 test
...
/ # touch test/testfile3
touch: test/testfile3: Permission denied

原因分析与解决方案 #

1. 自定义卷bind配置无效的修复 #

Docker Compose中使用local卷加driver_opts实现bind mount时，若已存在同名旧卷，Docker会复用旧配置而非应用新的driver_opts。需先清理旧卷再重新部署：

docker compose down -v
docker compose up -d

注：这种方式创建的是"绑定卷"，docker inspect显示的Mountpoint是Docker内部挂载点，实际会绑定到你指定的device路径，可通过容器内文件与主机是否同步来验证，无需关注Mountpoint字段。

2. 权限显示为nobody的核心原因及解决 #

场景一：主机目录为NFS或网络存储挂载

若主机目录是NFS挂载，NFS服务器的UID/GID映射与主机不一致，会导致容器内解析为nobody。可：

• 测试环境下在NFS导出配置中添加no_root_squash
• 确保NFS服务器上的UID/GID与容器内有效用户匹配

场景二：Docker启用了userns-remap

Docker的用户命名空间映射功能会将主机UID/GID映射到容器内的范围，导致主机用户在容器内显示为nobody。先检查是否启用：

docker info | grep "User Namespace"

若显示User Namespace: Enabled，可通过以下方式处理：

• 禁用映射：修改/etc/docker/daemon.json后重启Docker

  {
    "userns-remap": ""
  }
  

• 调整映射规则：修改/etc/subuid和/etc/subgid，让主机的UID/GID映射到容器内的有效范围

3. 容器权限的适配方案 #

若不想禁用userns-remap，可在docker-compose.yml中指定容器运行的UID/GID，与主机目录所有者匹配：

services:
  utility:
    container_name: alpine-test
    image: alpine:latest
    user: "1000:1000"  # 替换为主机pstewart的UID和dev组的GID
    volumes:
      - /opt/dev/fleet-forge/services/test:/test:rw
    command: sleep infinity

先通过id pstewart获取对应UID/GID：

$ id pstewart
uid=1000(pstewart) gid=1000(dev) groups=1000(dev),...

内容的提问来源于stack exchange，提问作者Paul Stewart