“没有这样的文件或目录”来自Linux，我看到了以下原因:

第一个原因是容器中没有文件。有些人试图从主机运行命令，而不将其添加到映像中。有些人通过在他们想要运行的命令之上安装一个卷来掩盖他们的命令。如果你运行相同的容器，但是使用shell而不是普通的entrypoint/cmd值，并运行ls /path/to/cmd，你会看到它是否存在。

下一个原因是运行了错误的命令。这通常出现在json/exec格式的命令不能正确解析的情况下。如果你看到一个命令试图运行["app"，或类似的东西，json字符串没有被Docker解析，Linux正试图使用shell将该命令解析为字符串。如果你打乱了参数的顺序，这也会发生，例如，试图运行-这是一个标志，你试图把标志放在图像名称之后，而它们必须放在图像名称之前。

对于shell脚本，如果第一行带有#!指向容器中不存在的命令。对于某些人来说，这是试图在只有/bin/sh的映像中运行bash。在你的例子中，这可以来自脚本中的Windows换行。在编辑器中切换到Linux/Unix换行将会纠正这个错误。

对于二进制文件，如果缺少链接库，则出现此错误。我经常看到这样的情况:使用libc编译的Go命令，但在alpine上使用musl或scratch运行，根本没有任何库。您需要包含所有缺失的库，或者静态编译您的命令。要查看这些库链接，请在二进制文件中使用ldd /your/app。

请注意类似的错误，例如:

standard_init_linux.go:211: exec user process caused "no such file or directory"

如果为其构建映像的体系结构与您的系统不匹配，就会发生这种情况。例如，试图在x86_64机器上运行为arm64构建的映像会生成此错误。

在我的例子中，我不得不将run.sh文件的行尾从CRLF更改为LF，错误就消失了。

这是CRLF的问题。我用这个解决了这个问题:

git config --global core.eol lf

git config --global core.autocrlf input

find . -type f -print0 | xargs -0 dos2unix

更改入口点如下所示。这对我很有效

ENTRYPOINT ["sh","/run.sh"]

正如tuomastik在评论中指出的，文档要求第一个参数是可执行文件:

ENTRYPOINT有两种形式: ENTRYPOINT["可执行"，"param1"， "param2"] (exec表单，首选) ENTRYPOINT命令param1 param2 (shell形式)

假设在alpine容器中运行go二进制时遇到这个问题。在构建bin之前导出以下变量

# CGO has to be disabled for alpine
export CGO_ENABLED=0

然后去构建