Articles

Fix Docker "exec user process caused: no such file or directory (2026)

April 16, 2026 5 min read

This error means the Docker daemon tried to run a program inside your container, but the operating system couldn’t find the executable file for that program.

Here are the most common reasons this happens and how to fix them:

1. Incorrect CMD or ENTRYPOINT in Dockerfile

The CMD or ENTRYPOINT instruction in your Dockerfile specifies the command to run when the container starts. If this command is misspelled, points to a non-existent file, or is in the wrong format, you’ll see this error.

  • Diagnosis: Inspect your Dockerfile. Look for the CMD and ENTRYPOINT lines.
  • Fix: Ensure the command and its arguments are correctly spelled and that the executable exists at the specified path within the container.
    • Example (Shell form): CMD ["/app/my_script.sh"] - This runs /app/my_script.sh directly.
    • Example (Exec form): CMD /app/my_script.sh - This also runs /app/my_script.sh. The exec form is generally preferred as it avoids an unnecessary shell process.
    • Why it works: The exec form directly invokes the executable, while the shell form invokes /bin/sh -c <command>, which might be the issue if /bin/sh or the command itself is not found. If you intend to use shell features like environment variable expansion, use the shell form explicitly.
  • If using ENTRYPOINT and CMD together: The CMD provides default arguments to the ENTRYPOINT. Ensure both are correctly specified. ENTRYPOINT ["/app/my_executable"] CMD ["--default-arg"]

2. Wrong Architecture for the Executable

You might have built your Docker image on one architecture (e.g., amd64) but are trying to run it on a different architecture (e.g., arm64 on an M1 Mac). The executable inside the container is compiled for the wrong CPU architecture.

  • Diagnosis:

    • Check your host machine’s architecture: uname -m (e.g., x86_64, aarch64).

    • Inspect the image’s architecture: docker image inspect <image_name> --format '{{.Architecture}}'

    • If you have shell access to a running container, check the architecture of the executable: docker run --rm <image_name> uname -m

  • Fix: Rebuild your Docker image specifically for the target architecture.
    • If building on an amd64 machine for arm64 (e.g., M1 Mac), use docker buildx.
      docker buildx create --use
docker buildx build --platform linux/arm64 -t your-image-name .
    • If building on an arm64 machine for amd64, use docker buildx with linux/amd64.
    • Why it works: buildx allows you to build multi-architecture images or cross-compile for a specific architecture, ensuring the executable inside the container matches the CPU your Docker daemon is running on.

3. Missing Interpreter (e.g., #!/bin/sh or #!/usr/bin/env python)

If your executable is a script (like a shell script or Python script) and the shebang line (e.g., #!/bin/sh or #!/usr/bin/env python3) at the top of the script is incorrect or the interpreter itself is not installed in the container, you’ll get this error. The OS tries to execute the script, sees the shebang, and then tries to find and run the interpreter specified there.

  • Diagnosis:
    • Examine the first line of your script file within the container.
    • Check if the interpreter specified in the shebang exists in the container’s filesystem. For example, if it’s #!/bin/sh, check if /bin/sh exists.
  • Fix:
    • Correct the shebang: Ensure it points to the correct interpreter path. #!/usr/bin/env python3 is often more portable than #!/usr/bin/python3.
    • Install the interpreter: If the interpreter is missing, add it to your Dockerfile.
      • For Debian/Ubuntu: RUN apt-get update && apt-get install -y python3
      • For Alpine: RUN apk update && apk add python3
    • Why it works: The shebang line tells the kernel which program should interpret the script. If that interpreter isn’t found, the kernel can’t execute the script. Installing the interpreter or correcting the path makes it findable.

4. File Permissions or Ownership Issues

The executable file might not have execute permissions, or it might be owned by a user that doesn’t have permission to run it.

  • Diagnosis:
    • Get a shell into a container created from your image: docker run -it --rm <image_name> /bin/bash (or sh).
    • Navigate to the directory of your executable and run ls -l <executable_name>. Check the permissions string (e.g., -rwxr-xr-x).
    • Check the owner and group.
  • Fix:
    • In your Dockerfile, add a RUN command to set execute permissions:
      COPY your_script.sh /app/your_script.sh
RUN chmod +x /app/your_script.sh
    • If ownership is the issue, ensure the user running the process in the container has read and execute permissions. You might need to adjust USER directives or chown the file.
    • Why it works: The operating system requires the execute permission bit to be set on a file before it can be run as a program.

5. Corrupted or Incomplete File Transfer

If the executable file was copied into the container and the copy process was interrupted or corrupted, the file might be incomplete or malformed, leading to this error.

  • Diagnosis:
    • Check the file size of the executable inside the container (docker run --rm <image_name> ls -l /path/to/executable).
    • Compare this size to the original file on your host.
    • If possible, re-copy the file and try building again.
  • Fix: Ensure your COPY or ADD commands in the Dockerfile complete successfully. Sometimes, network issues during build or issues with the Docker daemon’s storage can cause this. A clean build might resolve it:
    docker builder prune -a
docker image prune -a
docker system prune -a
docker build -t your-image-name .
    • Why it works: A clean build ensures that the file is copied fresh and completely into the container’s filesystem, free from any previous corrupted states.

6. Executable File is Not Actually an Executable (e.g., a directory or a text file)

You might be trying to execute something that isn’t a binary or a script meant to be executed.

  • Diagnosis:
    • Use docker run --rm <image_name> file /path/to/your/executable to inspect the file type.
    • If it reports "directory," "ASCII text," "data," etc., it’s not an executable.
  • Fix: Ensure the path in your CMD or ENTRYPOINT correctly points to an actual executable binary or a script with a valid shebang.
    • Why it works: The operating system can only execute files that are recognized as program binaries or scripts.

The next error you’ll likely encounter after fixing this is related to the container exiting immediately after startup if your CMD or ENTRYPOINT command finishes successfully without keeping the container alive (e.g., a web server that starts and then stops).

Want structured learning?

Take the full Docker course →