别急，我们一步步拆解问题——既然项目在OpenShift上能正常构建运行，说明核心逻辑没问题，大概率是本地环境的细节差异导致的，我们从几个方向排查：

1. 先确认构建上下文与本地文件结构 #

• 先检查你执行docker build命令时所在的目录：Docker的COPY . /tmp/app是基于构建上下文（也就是当前执行build的目录）来复制文件的。如果start.sh不在这个目录或其子目录里，COPY指令自然复制不到。
• 在build目录下执行ls -la，确认start.sh确实存在，且文件名没有大小写错误（Linux环境严格区分大小写，比如Start.sh和start.sh是完全不同的文件）。

2. 验证镜像内是否真的复制了文件 #

可以先跳过启动命令，构建镜像后进入容器直接查看：

docker build -t my-local-app .
docker run -it --entrypoint /bin/sh my-local-app
# 进入容器后执行以下命令查看文件
ls -la /tmp/app

如果这里看不到start.sh，那确实是COPY指令的问题；如果能看到，那问题出在脚本执行阶段。

3. 文件存在但无法执行？检查权限与换行符 #

• 权限问题：start.sh需要具备可执行权限。你可以在本地先执行chmod +x start.sh，再重新构建；或者直接在Dockerfile里添加权限设置：

  RUN chmod +x /tmp/app/start.sh
  

• 换行符问题：Mac默认使用CRLF换行，而Linux容器内的shell脚本要求LF换行。如果start.sh是在Mac上编辑的，可能会因为换行符不兼容导致看似“找不到文件”的错误（实际是脚本无法被shell解析）。你可以用dos2unix start.sh转换格式，或者在Dockerfile里添加处理：

  RUN sed -i 's/\r$//' /tmp/app/start.sh
  

4. 检查启动命令的路径是否正确 #

确认Dockerfile里的CMD或ENTRYPOINT指令路径无误：

• 如果写的是CMD ["./start.sh"]，要确保容器的工作目录是/tmp/app，可以提前添加WORKDIR /tmp/app；
• 更稳妥的方式是使用绝对路径：CMD ["/tmp/app/start.sh"]。

5. 针对Mac Sierra的特殊注意点 #

Mac Sierra支持的Docker Desktop版本有限（最高支持2.4.0.0），如果你的Docker版本过旧，可能存在语法兼容问题。建议检查当前Docker版本，若版本太旧，升级到对应兼容的最新版试试。

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