出现这样的错误有几种可能的原因。

在我的例子中，这是由于可执行文件(docker-entrypoint.sh来自鬼博客Dockerfile)在我下载后缺乏可执行文件模式。

解决方法:chmod +x docker-entrypoint.sh

在错误信息中显示:

无法启动容器foo_1: \ exec: "grunt serve":在$PATH中找不到可执行文件

它抱怨它无法找到可执行的grunt service，而不是它无法找到带有参数serve的可执行grunt。对于这个特定的错误，最可能的解释是使用json语法运行命令:

[ "grunt serve" ]

在你的合成文件中。这是无效的，因为json语法要求您拆分通常由shell在每个空格上拆分的每个参数。例如:

[ "grunt", "serve" ]

另一种可能的方法是在docker run命令中将它们引用到一个参数中。

docker run your_image_name "grunt serve"

在这种情况下，你需要删除引号，这样它就可以作为单独的参数传递给run命令:

docker run your_image_name grunt serve

对于其他人来说，未找到可执行文件意味着Linux看不到您试图在容器中使用默认$PATH值运行的二进制文件。这可能意味着有很多可能的原因，下面是一些:

Did you remember to include the binary inside your image? If you run a multi-stage image, make sure that binary install is run in the final stage. Run your image with an interactive shell and verify it exists: docker run -it --rm your_image_name /bin/sh Your path when shelling into the container may be modified for the interactive shell, particularly if you use bash, so you may need to specify the full path to the binary inside the container, or you may need to update the path in your Dockerfile with: ENV PATH=$PATH:/custom/dir/bin The binary may not have execute bits set on it, so you may need to make it executable. Do that with chmod: RUN chmod 755 /custom/dir/bin/executable The binary may include dynamically linked libraries that do not exist inside the image. You can use ldd to see the list of dynamically linked libraries. A common reason for this is compiling with glibc (most Linux environments) and running with musl (provided by Alpine): ldd /path/to/executable If you run the image with a volume, that volume can overlay the directory where the executable exists in your image. Volumes do not merge with the image, they get mounted in the filesystem tree same as any other Linux filesystem mount. That means files from the parent filesystem at the mount point are no longer visible. (Note that named volumes are initialized by docker from the image content, but this only happens when the named volume is empty.) So the fix is to not mount volumes on top of paths where you have executables you want to run from the image. If you run a binary for a different platform, and haven't configured binfmt_misc with the --fix-binary option, qemu will be looking for the interpreter inside the container filesystem namespace instead of the host filesystem. See this Ubuntu bug report for more details on this issue. If the error is from a shell script, the issue is often with the first line of that script (e.g. the #!/bin/bash). Either the command doesn't exist inside the image for a reason above, or the file is not saved as ascii or utf8 with Linux linefeeds. You can attempt dos2unix to fix the linefeeds, or check your git and editor settings.

我也有同样的问题，在谷歌上搜索了很多次后，我不知道如何解决它。

突然我发现我犯了个愚蠢的错误:)

正如文档中提到的，docker run的最后一部分是加载容器后要运行的命令及其参数。

不是容器名!!

这是我的尴尬错误。

下面我为您提供了我的命令行图片，以查看我做错了什么。

这就是文档中提到的修复。

这是我粘贴错误消息时谷歌上的第一个结果，这是因为我的参数顺序不对。

容器名必须在所有参数之后。

Bad:

docker run <container_name> -v $(pwd):/src -it

好:

docker run -v $(pwd):/src -it <container_name>

Docker容器可以在没有shell的情况下构建(例如https://github.com/fluent/fluent-bit-docker-image/issues/19)。

在这种情况下，你可以复制一个静态编译的shell并执行它。

docker create --name temp-busybox busybox:1.31.0
docker cp temp-busybox:/bin/busybox busybox
docker cp busybox mycontainerid:/busybox
docker exec -it mycontainerid /bin/busybox sh

出于某种原因，除非我添加了“bash”澄清符，否则我会得到这个错误。甚至加上“#!”“/bin/bash”到我的入口点文件的顶部并没有帮助。

ENTRYPOINT [ "bash", "entrypoint.sh" ]