Ubuntu Docker构建问题：ENTRYPOINT执行提示‘No such file or directory’

以下是几种常见的原因及排查、解决方法：

1. 动态链接库依赖缺失 #

这是此类问题最常见的诱因。你的二进制文件mysolution-linux-amd64如果是基于glibc编译的，但使用的<base image>是Alpine这类采用musl libc的轻量发行版，系统会找不到对应的链接器（例如/lib64/ld-linux-x86-64.so.2），此时会抛出看似文件不存在的错误。

• 验证方式：

  • 本地执行ldd mysolution-linux-amd64查看二进制依赖；
  • 进入容器检查：docker run --rm -it <你的镜像名> /bin/sh，在容器内执行ldd /app/mysolution-linux-amd64。

• 解决办法：

  • 更换为基于glibc的基础镜像，比如ubuntu:latest、debian:stable-slim；
  • 若坚持使用Alpine，可安装glibc兼容包，或重新编译二进制时指定musl libc（例如Go语言项目添加CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build参数进行静态编译）。

2. 架构不匹配 #

如果你的二进制是amd64架构，但基础镜像或Docker运行环境是arm64/arm/v7等其他架构（比如M系列Mac），会导致无法执行二进制文件，同样可能触发该错误。

• 验证方式：

  • 本地执行file mysolution-linux-amd64查看二进制架构信息；
  • 查看基础镜像架构：docker inspect <base image> | grep Architecture。

• 解决办法：

  • 编译对应架构的二进制文件；
  • 使用Docker Buildx构建多架构镜像，或确保基础镜像与二进制架构一致。

3. 二进制文件损坏 #

虽然构建日志显示文件复制成功，但可能在复制过程中出现文件损坏。

• 验证方式：

  • 本地执行sha256sum src/mysolution-linux-amd64记录哈希值；
  • 进入容器执行sha256sum /app/mysolution-linux-amd64，对比两者是否一致。

• 解决办法：

  • 若哈希值不一致，重新复制文件或检查构建上下文是否正确，确保本地文件未损坏。

内容的提问来源于stack exchange，提问作者Krishnan V S