Introduction

Cannot start service web: OCI runtime create failed is not the root cause by itself. It is Docker telling you that the low-level container runtime could not create the container process. The real diagnosis is almost always in the text that comes after that phrase or in the container logs and daemon logs around it.

Treat the Message as a Wrapper, Not the Diagnosis

The phrase OCI runtime create failed appears around many different underlying failures, such as:

• invalid bind mounts
• bad entrypoint or command
• missing executable inside the image
• permission or security-policy problems
• unsupported architecture or binary format
• container process startup errors discovered before launch completes

So the first debugging step is to capture the full error, not to stop reading at the generic prefix.

Check the Full Docker Error and Container State

If the container was created far enough for Docker to know about it, inspect it and check logs.

docker compose up web

Then in another terminal:

docker ps -a
docker logs <container-id>
docker inspect <container-id>

If the container never starts at all, the most useful detail may come from the daemon output or the exact final clause after OCI runtime create failed.

Volume Mounts Are a Frequent Cause

One common cause is a bad bind mount. If the host path is wrong, inaccessible, or unexpectedly a file when the container expects a directory, the runtime may fail before the process starts.

A typical compose fragment to inspect looks like this:

1services:
2  web:
3    image: myapp
4    volumes:
5      - ./app:/usr/src/app

If ./app does not exist, or if the target path conflicts with something important inside the image, startup can fail. Verify the host path directly on the machine and simplify mounts until the container starts.

Missing or Invalid Entrypoint Is Another Common Cause

If the image tries to execute a file that does not exist or does not have execute permission, the runtime may stop at container creation.

Example Dockerfile fragment:

1FROM python:3.12-slim
2WORKDIR /app
3COPY . .
4CMD ["python", "server.py"]

If server.py is missing from the image, or if ENTRYPOINT points at a nonexistent shell script, Docker will fail before the service becomes healthy.

To debug, override the entrypoint temporarily:

docker run --rm -it --entrypoint /bin/sh myimage

If that shell starts, inspect the filesystem and confirm the expected startup command exists.

Architecture and Binary Mismatch Also Fit This Error

On Apple Silicon, mixed x86 and ARM images can trigger confusing runtime failures. The same applies when a container tries to launch a binary compiled for the wrong architecture.

Check the image architecture and, if necessary, force the platform explicitly in Compose or during image build. An exec format error hidden under the OCI runtime wrapper often points in this direction.

Security and Permission Problems Matter Too

SELinux, AppArmor, file permissions, or rootless Docker constraints can all block the runtime from creating the container the way the configuration requests.

This is especially common when:

• mounting sensitive host directories
• using privileged features
• binding to host paths with restrictive ownership
• trying to execute scripts copied without executable permission

If a shell script is the entrypoint, make sure it is executable inside the image:

COPY docker-entrypoint.sh /usr/local/bin/
RUN chmod +x /usr/local/bin/docker-entrypoint.sh
ENTRYPOINT ["/usr/local/bin/docker-entrypoint.sh"]

Simplify Until the Container Starts

The fastest debugging pattern is usually to strip the service down to a minimal working version and add complexity back one piece at a time.

For example:

• remove custom mounts
• remove custom entrypoint
• run a shell instead of the app command
• confirm the base image starts
• add mounts back one by one
• restore the real command last

This is much more effective than guessing from the generic error prefix.

Common Pitfalls

The biggest mistake is treating OCI runtime create failed as the full diagnosis. It is only the wrapper around the actual failure.

Another mistake is changing several Compose settings at once. That makes it harder to identify whether the real issue is the mount, the command, the image, or the environment.

Developers also forget to verify the image contents directly, even though a missing startup script or wrong path is one of the most common causes.

Summary

• 'OCI runtime create failed is a generic container-startup wrapper, not the specific root cause.'
• Read the rest of the error message and inspect logs, container state, and daemon output.
• Bad mounts, missing entrypoints, permission issues, and architecture mismatches are common causes.
• Simplify the container configuration until it starts, then add pieces back incrementally.
• Debug the concrete startup command and filesystem layout, not just the generic Docker prefix.