🚨 Kubernetes Error Guide: 'CreateContainerError' Runtime Create Failure

Exact Error Message

NAME                       READY   STATUS                RESTARTS   AGE
worker-5f7c9d8b6c-r4n8t    0/1     CreateContainerError  0          34s

# kubectl describe pod worker-5f7c9d8b6c-r4n8t
Events:
  Type     Reason                  Age              From     Message
  ----     ------                  ----             ----     -------
  Warning  Failed  11s (x4 over 34s)  kubelet
    Error: container create failed:
    time="..." level=error msg="runc create failed: unable to start container process:
    exec: \"/app/start.sh\": stat /app/start.sh: no such file or directory"

What the Error Means

CreateContainerError is reported when the image pulled successfully but the container runtime (containerd/CRI-O via runc) failed at the create step — after the image is ready but before the container actually runs. The kubelet hands a valid OCI spec to the runtime, and the runtime rejects it because something about the container’s configuration cannot be set up on the node.

This is distinct from CreateContainerConfigError (which is Kubernetes-side: a missing ConfigMap or Secret) and from RunContainerError (which is the start step). CreateContainerError is the runtime saying “I have the image, but I cannot construct this container as specified.”

Common Causes

• A command/entrypoint that does not exist in the image — exec: "/app/start.sh": no such file or directory.
• A hostPath mount whose source does not exist on the node, so the runtime cannot bind-mount it.
• A container name collision — a leftover container with the same name from a previous failed start that was not cleaned up.
• Invalid securityContext settings the runtime cannot apply (a non-existent user/UID, unsupported capabilities, or a seccomp profile that is missing).
• Device or sysctl requests the node cannot satisfy (e.g. requesting /dev/fuse without the device plugin).
• A corrupted image layer or runtime state on the node, often after a disk-full or unclean shutdown.
• A read-only or full root filesystem on the node preventing the runtime from writing container state.

How to Reproduce the Error

Point a container at a command that is not present in the image:

apiVersion: v1
kind: Pod
metadata:
  name: bad-cmd
spec:
  containers:
    - name: app
      image: busybox:1.36
      command: ["/app/start.sh"]   # not in the busybox image

kubectl apply -f bad-cmd.yaml
kubectl get pod bad-cmd
# STATUS: CreateContainerError

Diagnostic Commands

# Confirm the reason and the full runtime message
kubectl get pod <POD> -o jsonpath='{.status.containerStatuses[0].state.waiting.reason}{"\n"}'
kubectl describe pod <POD> | grep -A6 -iE 'createcontainererror|container create failed|runc'

# Inspect the requested command, mounts, and security context
kubectl get pod <POD> -o jsonpath='{.spec.containers[0].command} {.spec.containers[0].args}{"\n"}'
kubectl get pod <POD> -o jsonpath='{.spec.containers[0].volumeMounts}{"\n"}'
kubectl get pod <POD> -o jsonpath='{.spec.containers[0].securityContext}{"\n"}'

# On the node: confirm a hostPath source exists
ls -ld /path/from/hostpath

# On the node: look for stale containers or runtime errors (containerd)
crictl ps -a | grep <POD>
crictl pods | grep <POD>
journalctl -u containerd --since "10 min ago" | grep -i error

# Confirm node disk is not full (a common create-step failure)
kubectl describe node <NODE> | grep -iE 'diskpressure|allocatable'

Step-by-Step Resolution

1. Read the exact runtime message. The describe event contains the precise cause — a missing binary, a mount path, or a security setting:

kubectl describe pod <POD> | grep -A6 'container create failed'

2. If the entrypoint is missing, fix the command or the image. Verify the binary exists in the image and the path is correct:

kubectl run probe --rm -it --image=<IMAGE> --command -- ls -l /app/

Then correct the command/args to a path that exists.

3. If a hostPath is missing, create it or fix the path. The runtime cannot bind-mount a source that does not exist. Either pre-create the directory via a DaemonSet/node provisioning step, or set hostPath.type appropriately (e.g. DirectoryOrCreate).

4. Clear a stale container name collision. If a previous failed container was left behind, remove it on the node:

crictl ps -a | grep <CONTAINER_NAME>
crictl rm <CONTAINER_ID>

Then delete the pod so the kubelet recreates it cleanly.

5. Fix invalid securityContext or device requests. Ensure any runAsUser UID exists in the image, requested capabilities are supported, and any device plugin (FUSE, GPU) is installed before requesting its resource.

6. If the node itself is unhealthy, drain it. Disk-full or corrupted runtime state affects every new container; cordon and investigate:

kubectl cordon <NODE>
kubectl describe node <NODE> | grep -i pressure

Prevention and Best Practices

• Validate that command/entrypoint paths exist in the image as part of CI image testing.
• Avoid hostPath mounts where possible; when required, use type: DirectoryOrCreate or pre-provision the path on every node.
• Keep node disks monitored — many CreateContainerError cases are really DiskPressure in disguise.
• Test any non-trivial securityContext (custom UID, dropped capabilities, seccomp) in a staging cluster before production.
• Install required device plugins before scheduling pods that request special devices.
• Set up alerting on pods stuck in CreateContainerError so a degraded node is caught before it spreads. See more in Kubernetes & Helm guides.

Related Errors

• CreateContainerConfigError — Kubernetes could not assemble the container config (missing ConfigMap/Secret), before the runtime is even called.
• RunContainerError — creation succeeded but the runtime failed to start the process.
• RunContainerError: exec format error — the binary architecture does not match the node.
• CrashLoopBackOff — the container created and started but the process keeps exiting.

Frequently Asked Questions

What is the difference between CreateContainerError and CreateContainerConfigError? CreateContainerConfigError is a Kubernetes-side failure to build the container spec — typically a missing ConfigMap, Secret, or environment reference. CreateContainerError happens later: the spec was valid, but the container runtime rejected the create call on the node.

The image works fine locally with docker run. Why does Kubernetes fail? Differences in mounts, security context, user, or the runtime (containerd vs Docker) can surface only under Kubernetes. Read the runc create failed message — it names the exact missing path, user, or capability.

Could a full node disk cause this? Yes. When the node is under disk pressure, the runtime may be unable to write container state and fails the create step. Check kubectl describe node for DiskPressure and free space before blaming the pod spec.

Why does deleting and recreating the pod sometimes fix it? When the cause is a stale container name collision or a transient runtime state issue, a clean recreate lets the runtime start fresh. If the root cause is the pod spec (bad command, missing mount), recreating will reproduce the same error.