ContainerCannotRun: The runtime accepted the container and the process could not be executed

This termination reason means the container was created but its process could not be run. The message names the specific reason, and it is almost always something inside the image.

Applies to: All Kubernetes versions

What it means

ContainerCannotRun appears as a container's termination reason when the runtime got as far as starting the process and the execution itself failed. It sits between configuration problems, which fail earlier, and application failures, which produce an exit code. The causes are the same family as RunContainerError: a missing binary, a missing shared library, a working directory that does not exist, a user that is not present in the image, or an architecture mismatch. What distinguishes this reason is that it is reported on the container's status rather than as a creation event, so it shows up in Last State rather than in the pod's event list.

Most common causes

• The command or entrypoint does not exist at the path given.
• A dynamically linked binary missing a shared library or its loader.
• A workingDir that does not exist inside the image.
• runAsUser naming a UID with no permission to execute the entrypoint.
• An architecture mismatch between the image and the node.
• A required device or mount unavailable at execution time.

How to diagnose it

1. Read the message alongside the reason: kubectl describe pod POD under Last State.
2. Run the image locally with an overridden entrypoint and inspect the path in question.
3. Check dynamic dependencies: ldd /path/to/binary inside the image.
4. Verify workingDir exists in the image.
5. Compare the image's architecture with the node's.

How to fix it

1. Correct the command path or install what is missing in the image.
2. Build against the runtime image's libc, or use a base image that provides the needed libraries.
3. Create the working directory in the image, or remove workingDir from the spec.
4. Use a UID that exists in the image and can execute the entrypoint.
5. Build multi-architecture images, or pin the workload to matching nodes.

Notes

This reason and RunContainerError cover overlapping ground and different runtimes favour different wordings for the same underlying problem. Matching on the message rather than the reason is more reliable across containerd and CRI-O.

Related

• RunContainerError — The container was created but failed to start
• exec format error — The binary is for a different architecture

Sources

• Kubernetes documentation — Pod Lifecycle: container states
• Kubernetes documentation — Debug Pods
• OCI Runtime Specification