OCI runtime create failed: The low-level runtime refused to create the container

This error comes from the OCI runtime beneath containerd or CRI-O. The text after the phrase is the real message, and it is usually specific — a missing path, a rejected capability, a mount that will not work.

Applies to: All Kubernetes versions using an OCI runtime such as runc or crun

What it means

Kubernetes talks to a high-level runtime — containerd or CRI-O — which in turn calls an OCI runtime such as runc to actually create the container from a specification. When runc refuses, the error is wrapped and passed back up, arriving in pod events as OCI runtime create failed: …. Everything before the colon is packaging; everything after it is the diagnosis. Because runc is operating at the level of namespaces, cgroups, mounts, and capabilities, its messages tend to name a specific system object, which makes them more actionable than most Kubernetes-level errors once you know to read past the wrapper.

Most common causes

• The container's command does not exist in the image, producing an exec: … no such file or directory suffix.
• A mount source path that does not exist on the node, common with hostPath volumes.
• A security setting the runtime cannot apply — a capability, a seccomp profile, or an AppArmor profile that is not loaded on the node.
• A cgroup driver mismatch between the kubelet and the runtime.
• A read-only or full filesystem preventing the container's working directories from being created.
• A device requested by the container that is not present on the node.
• Kernel features the runtime requires being unavailable, which happens on unusual or hardened kernels.

How to diagnose it

1. Read the text after OCI runtime create failed in kubectl describe pod POD. That is the actual error.
2. If it names a path, check whether that path exists — inside the image for a command, on the node for a mount source.
3. Check the runtime's own log on the node, which usually has more context: journalctl -u containerd.
4. Check the cgroup driver on both sides: the kubelet's configuration and the runtime's, which must agree.
5. For a security profile, confirm it is loaded on the node — a profile named in the pod spec but absent on the node fails here.
6. Try the same image with crictl directly on the node to isolate Kubernetes from the runtime.

How to fix it

1. Correct the command path, or install what the image is missing.
2. Create the hostPath directory on the node, or use a volume type that does not depend on node layout.
3. Load the required seccomp or AppArmor profile onto every node that will run the workload.
4. Align the cgroup driver between the kubelet and the container runtime. Mismatch causes a broad range of confusing failures beyond this one.
5. Free disk space if the node cannot create the container's directories.
6. Remove requests for devices the node does not have, or schedule the pod only onto nodes that do.

Notes

The wrapper text is identical across a very wide range of underlying problems, so searching for the phrase itself is unproductive. The suffix is what distinguishes a missing binary from a cgroup driver mismatch, and they share nothing.

Related

• failed to create shim task — The runtime shim could not start the container process
• CreateContainerError — The runtime failed to create the container

Sources

• Kubernetes documentation — Container Runtime Interface
• OCI Runtime Specification
• runc — OCI container runtime