Docker Compose中command指令与容器内手动执行命令的权限差异问题

问题重现 #

通过Docker Compose的command指令直接执行/worker/bin/init.sh脚本，容器启动后部分文件读权限丢失；但将容器改为后台运行（比如用command: vim tmpfile），再通过docker exec进入容器手动执行同一脚本，权限完全正常。

相关配置与操作：

• docker-compose.yml核心配置：

version: '2'
services:
  container_1:
    image: ...
    command: /worker/bin/init.sh
    volumes: ...
    cap_add:
      - SYS_ADMIN
      - SYS_PTRACE
      # 其他配置省略

• 启动命令：

docker-compose -f docker-compose.yml up -d

• 手动执行流程：修改command为vim tmpfile启动容器 → docker exec -ti container_1 bash进入容器 → 手动运行/worker/bin/init.sh

可能的原因及解决思路 #

1. 执行脚本的用户身份不一致 #

Docker Compose的command默认用镜像的默认用户跑脚本（可能是root，也可能是镜像指定的非root用户），而docker exec进入容器时，默认用的是容器启动用户，但如果脚本里有依赖用户权限上下文的操作，就会出现差异。

• 排查：在init.sh开头加两行：

  whoami
  id
  

  分别用两种方式执行，对比输出的用户信息是否一致。
• 解决：在docker-compose.yml里显式指定user: root（或你需要的用户），确保command和手动执行的用户身份统一。

2. 环境变量差异导致权限设置异常 #

docker exec进入容器后会加载交互式shell的环境变量（比如.bashrc、.profile），但command直接跑脚本时不会加载这些配置。如果脚本里依赖UMASK这类影响权限的变量，就会导致文件权限设置不同。

• 排查：在init.sh开头加env命令，对比两种执行方式下的环境变量，重点看UMASK的值。
• 解决：在脚本开头手动加载环境配置，比如source /root/.bashrc，或者直接显式设置umask 022（确保文件默认有读权限）。

3. 卷挂载的权限同步问题 #

如果/worker是挂载的宿主机卷，Docker Compose启动时挂载卷的时机和手动执行脚本的时机可能有差异，导致脚本修改权限时，卷的权限还没同步完成，或者挂载时的权限覆盖了脚本的修改。

• 排查：检查volumes配置有没有加:ro（只读）；对比宿主机对应目录和容器内挂载目录的权限。
• 解决：确保卷是可读写挂载（默认就是，除非显式加:ro）；如果宿主机目录有特定属主，在docker-compose.yml里设置user字段让容器用户和宿主机目录属主一致，避免权限冲突。

4. PID 1进程的特殊行为 #

command执行的脚本是容器的PID 1进程，Linux里PID 1的信号处理、资源限制和普通进程不一样，某些权限修改操作在PID 1下可能有特殊表现。

• 排查：把command改成bash -c "/worker/bin/init.sh; sleep infinity"，让脚本在bash子进程里跑，不是PID 1，看权限问题是否消失。
• 解决：不要让脚本直接当PID 1运行，用shell包裹执行；或者在docker-compose.yml里加init: true（Docker 19.03+支持），用tini处理PID 1的特殊情况。

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