Docker Desktop Dev Environment运行脚本报permission denied错误

权限报错的核心原因是不同场景下文件权限位的保留逻辑不一致：

• 本地通过目录挂载运行时，本地存储的mongosetup.sh已经被手动配置过可执行权限，挂载进容器后权限位保留，可直接运行
• Docker Desktop Dev Environment从Git拉取代码构建时，Git默认不会主动保留文件的可执行权限位（除非仓库中显式记录了该权限配置），拉取到容器内的脚本默认是644权限（无执行权限），直接作为入口点执行就会触发permission denied报错。
  脚本文件确实存在但无法执行，就是典型的缺少可执行权限位的表现。

选其中一种即可，不需要手动进容器改权限。

方案1（最省事，推荐） #

绕开脚本本身的可执行权限要求，修改mongo-setup服务的入口点配置，不直接执行脚本，而是调用容器内的bash解释器读取并运行脚本：

entrypoint: [ "bash", "/scripts/mongosetup.sh" ]

这种写法只要求挂载的脚本文件具备可读权限即可，无论Git拉下来的文件权限是什么，只要能读就能正常执行，完全适配Dev Environment的构建逻辑，不需要额外修改仓库文件权限。

方案2 #

让Git跟踪脚本的可执行权限位，本地执行以下命令提交权限变更到仓库：

chmod +x .docker/scripts/mongosetup.sh
git update-index --chmod=+x .docker/scripts/mongosetup.sh
git commit -m "add execute permission for mongo setup script"
git push

提交后Git仓库会记录该脚本的可执行属性，Dev Environment拉取代码时会自动给脚本加上执行权限，原有entrypoint配置不用改也能正常运行。

Dev Environment转换compose配置时的$转义bug，可以通过改用exec格式的healthcheck写法绕开，完全不在配置里写shell变量展开逻辑，从根源避免转义问题：

healthcheck:
  test: ["CMD", "mongosh", "--quiet", "--eval", "try { rs.status().ok } catch (e) { rs.initiate().ok }"]
  interval: 10s
  start_period: 30s

这种数组形式的配置不会触发compose的变量替换逻辑，无论Dev Environment怎么转换生成专属配置文件，都不会出现$转义失败的问题。

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