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

git config --global core.eol lf

git config --global core.autocrlf input

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

你可以在Mac上使用BBEdit来排序这个问题，因为notepad++不可用。

从窗户底部就能看出来。除了字符集选项

这里有多个正确答案。我没有看到它的VIM版本，所以在这里。在VIM中打开文件，检查底部状态行，例如，执行set ff=dos(用于CRLF)或set ff=unix(用于LF)。

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

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

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

“没有这样的文件或目录”来自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。

存在的问题:

The problem comes from the .sh file. First we must remember that Windows uses \r\n as the end of the line, while Linux and Mac use \n. Git has a feature called autoclrf that is generally set to “true” on Windows. This automatically converts \n to \r\n upon completion of the download from a Git repository, but Git does not make any kind of notice of this, hence the error is generated. This process is good, at least for the other files, but it is not the case for bash files, as is the case for the entrypoint.sh file.

立即解决方案:

打开您最喜欢的代码编辑器并更改导致冲突的文件的行结束符，在我们的示例中是:entrypoint.sh。你可以在软件右下角的Visual Studio Code中做到这一点，单击CRLF，并将文件行的末尾更改为LF。

从下面的链接阅读整篇文章，找到永久的解决方案:

https://davidcasr.medium.com/docker-standard-init-linux-go-211-exec-user-process-caused-no-such-file-or-directory-en-c0cb42edb295