在我的情况下，我命令参数错误移动所有开关之前的图像名称

我也发现了同样的问题。我做了以下事情:

docker run -ti devops -v /tmp:/tmp /bin/bash

当我把它改成

docker run -ti -v /tmp:/tmp devops /bin/bash

它工作得很好。

指标题。

我的错误是在docker运行期间通过——env-file放置变量。在其他文件中，该文件包含一个PATH扩展名:PATH=$PATH:something，这导致PATH var看起来像PATH=$PATH:something (var解析没有执行)，而不是PATH:/usr/bin…:something。

我不能使决议工作通过- ENV -file，所以我看到这个工作的唯一方式是通过使用Dockerfile中的ENV。

在我的情况下，我命令参数错误移动所有开关之前的图像名称

在错误信息中显示:

无法启动容器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容器可以在没有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