exec: "dotnet": executable file not found in $PATH from a .NET container built on mcr.microsoft.com/dotnet/runtime-deps means the image has no dotnet program at all. Use the runtime image for a framework-dependent publish, or publish self-contained and start the app's own executable.

In the test, a self-contained publish for linux-x64 with ENTRYPOINT ["./ClinicApi"] started on the same runtime-deps image.

The error

PS> docker run --rm --name fix10-dn-deps fix10-dn-deps
docker: Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: exec: "dotnet": executable file not found in $PATH

Run 'docker run --help' for more information

The docker run command exited with code 127.

Why it happens

The Dockerfile ran dotnet publish -c Release -o /out with no runtime identifier and no --self-contained, which left ClinicApi.dll and its runtimeconfig file in /out, and copied it onto mcr.microsoft.com/dotnet/runtime-deps:10.0 with ENTRYPOINT ["dotnet", "ClinicApi.dll"]. The runtime-deps image reported Ubuntu 24.04.5 LTS in /etc/os-release, and Docker found no dotnet in its $PATH. Docker fails before the app is reached, which is why the message comes from the daemon and runc, not from .NET.

Read the message from the end. The part after the last colon, exec: "dotnet": executable file not found in $PATH, names the program Docker tried to start, which is the first word of the ENTRYPOINT. Everything before it, about the shim task and runc, is Docker reporting that the start failed.

The image name invites the mistake: "runtime-deps" reads like "runtime plus dependencies", but the image used here had no dotnet to start.

The fix

FROM mcr.microsoft.com/dotnet/sdk:10.0 AS build
WORKDIR /src
COPY ClinicApi.csproj .
RUN dotnet restore -r linux-x64
COPY Program.cs .
RUN dotnet publish -c Release -r linux-x64 --self-contained true -o /out --no-restore

FROM mcr.microsoft.com/dotnet/runtime-deps:10.0
WORKDIR /app
COPY --from=build /out .
ENTRYPOINT ["./ClinicApi"]
PS> docker run --rm --name fix10-dn-deps2 fix10-dn-deps-sc
ClinicApi started on .NET 10.0.10

The self-contained publish carries its own runtime, so the entry point is the app's executable, not dotnet. Note the version: the self-contained app ran on .NET 10.0.10, the same version that dotnet --list-runtimes printed in the sdk:10.0 build image, while the runtime:10.0 image on this machine had 10.0.13. The other fix keeps the framework-dependent publish and changes only the FROM line to mcr.microsoft.com/dotnet/runtime:10.0; that image with the same dotnet ClinicApi.dll entry point started fine: 

PS> docker run --rm --name fix10-dn-dll3 fix10-dn-dllfix
ClinicApi started on .NET 10.0.13

How it was reproduced

A console app from dotnet new console -n ClinicApi, no packages, built in a multi-stage Dockerfile on mcr.microsoft.com/dotnet/sdk:10.0 (SDK 10.0.302). The failing image used mcr.microsoft.com/dotnet/runtime-deps:10.0 (pulled for this test) as the final stage. Docker engine 29.9.3 on Windows 11.

Frequently asked

Does the dotnet runtime-deps image include dotnet?
No. In the test the runtime-deps:10.0 image had no dotnet command, so ENTRYPOINT ["dotnet", "ClinicApi.dll"] failed with executable file not found in $PATH.
When should I use runtime-deps instead of the runtime image?
Use runtime-deps for a self-contained publish, which brings its own .NET runtime. Start the app's own executable, for example ENTRYPOINT ["./ClinicApi"].
How do I fix exec dotnet executable file not found in a .NET Dockerfile?
Either change the final FROM line to mcr.microsoft.com/dotnet/runtime:10.0, or publish with -r linux-x64 --self-contained true and run the executable instead of dotnet.

The same Docker message for a shell that is missing from an image is covered in exec: "bash": executable file not found in $PATH. More decoded errors in the Fixes category.