WSL下执行docker-compose up报permission denied错误如何解决

这个报错的核心触发逻辑是容器运行时无法执行指定的入口脚本，仅修改宿主机目录权限无法覆盖所有触发场景，按以下优先级排查处理：

1. 确认镜像内脚本的可执行位配置正确 #

绝大多数场景下，你在WSL宿主机修改文件权限不会同步到镜像内部的文件，只有构建阶段设置的权限才会生效。

• 检查Dockerfile的脚本拷贝逻辑，不要依赖Windows本地的权限设置（NTFS权限不会被Linux容器识别），推荐两种正确写法：
  写法1：拷贝后单独加执行权限

  COPY my_shell_script /my_path/my_shell_script
  RUN chmod +x /my_path/my_shell_script
  

  写法2：用COPY的--chmod参数直接指定权限（需要开启BuildKit，当前Docker Desktop默认开启）

  COPY --chmod=755 my_shell_script /my_path/my_shell_script
  

• 快速验证镜像内文件权限：临时修改docker-compose.yml中对应服务的入口命令，直接打印脚本权限：

  services:
    your_service_name:
      # 保留原有镜像、挂载等配置，临时覆盖入口
      entrypoint: ["ls", "-l", "/my_path/my_shell_script"]
  

  执行docker-compose up查看输出，如果权限位为-rw-r--r--，说明脚本没有可执行权限，重新构建镜像即可。

2. 排查WSL挂载参数导致的权限失效 #

如果你的脚本是通过volume从WSL宿主机挂载到容器内（不是构建在镜像里），大概率是WSL挂载Windows磁盘的默认参数限制：

• WSL默认挂载Windows盘符（对应/mnt/c/、/mnt/d/等路径）时，默认携带noexec参数，且不支持Linux权限位设置，哪怕手动执行chmod也不会生效，挂载到容器内的脚本自然无法执行。
• 验证方式：在WSL终端执行mount | grep /mnt/，查看脚本所在挂载点的输出，如果包含noexec字段就确认是该问题。
• 修复方式：
  1. 编辑WSL配置文件sudo nano /etc/wsl.conf，写入以下配置：

     [automount]
     options = "metadata,umask=0022,fmask=0011"
     mountFsTab = false
     

  2. 关闭所有WSL窗口，在Windows终端执行wsl --shutdown重启WSL实例
  3. 重新给脚本加执行权限chmod +x /your/wsl/path/to/my_shell_script，再启动容器即可。

3. 排查脚本换行符格式错误 #

如果脚本是在Windows环境下编辑后再传入WSL/构建进镜像，Windows默认的CRLF换行符会导致Linux无法正确识别脚本的shebang（第一行的#!/bin/bash之类的解释器声明），也会抛出permission denied报错，和文件本身权限无关。

• 验证方式：在WSL中进入脚本所在目录，执行file my_shell_script，如果输出包含with CRLF line terminators字样，就是换行符问题。
• 修复方式：执行sed -i 's/\r$//' my_shell_script将换行符转换为Unix标准的LF格式，或者在代码编辑器中将脚本的换行符设置为LF后重新构建镜像。

4. 特殊场景排查 #

如果以上操作都无效，按顺序验证：

• 检查脚本的shebang行是否正确，比如第一行写的#!/bin/bash但镜像内根本没有bash（比如极简alpine镜像默认用sh），也可能触发类似报错，可以临时把入口改成/bin/sh /my_path/my_shell_script测试能不能正常执行。
• 临时在docker-compose服务配置中加privileged: true测试，如果启动正常说明是AppArmor/SELinux的安全规则拦截，再针对性调整规则即可，生产环境不要长期开启特权模式。

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