Exec: "caddy": executable file not found in $PATH: unknown

1. The problem I’m having:

I’m building “successfully” a Caddy image with simply adding the module(s) or using xcaddy. Everytime I start a container after my build I get:

ERROR: for 7d9210273fce_caddy  Cannot start service caddy: failed to create shim: OCI runtime create failed: container_linux.go:380: starting container process caused: exec: "caddy": executable file not found in $PATH: unknown

I can change the run command path like:

command: caddy run --config /config/caddy-config.json

But that gives me:

ERROR: for 7d9210273fce_caddy  Cannot start service caddy: failed to create shim: OCI runtime create failed: container_linux.go:380: starting container process caused: exec: "/usr/bin/caddy": permission denied: unknown

2. Error messages and/or full log output:

Example 1:

ERROR: for 7d9210273fce_caddy  Cannot start service caddy: failed to create shim: OCI runtime create failed: container_linux.go:380: starting container process caused: exec: "caddy": executable file not found in $PATH: unknown

Example 2:

ERROR: for 7d9210273fce_caddy  Cannot start service caddy: failed to create shim: OCI runtime create failed: container_linux.go:380: starting container process caused: exec: "/usr/bin/caddy": permission denied: unknown

3. Caddy version:

2.7.5 (and lower same result)

4. How I installed and ran Caddy:

This is the last build I used. I also tried with ADD [caddy-download-page-link>] /usr/bin/caddy with the same result

FROM caddy:2.7.5-builder-alpine AS builder

RUN xcaddy build \
    --with github.com/caddy-dns/cloudflare 
        
FROM caddy:2.7.5-alpine

COPY --from=builder /usr/bin/caddy /usr/bin/caddy

a. System environment:

Docker

b. Command:

docker-compose -f ./docker-compose.yml up

c. Service/unit/compose file:

version: "3.7"

services:
  caddy:
#    image: caddy:2
    image: caddy:2-2-alpine-custom
    restart: always
    command: caddy run --config /config/caddy-config.json
    ports:
      - 80:80  # Needed for the ACME HTTP-01 challenge.
      - 443:443
    volumes:
      - /home/caddy/config/Caddyfile:/etc/caddy/Caddyfile
      - /home/caddy/config/caddy-config.json:/config/caddy-config.json
      - /home/caddy/data:/data

When using code blocks on the forums (or markdown in general), the ``` must be on its own lines. I fixed your post this time, but please mind your formatting next time.

That should work fine.

Are you sure this is correct? Did you tag your image that way? How did you actually build your image from your Dockerfile?

Normally you’d use the build: config in your compose.yml.

Yes the image name is fine; I have a docker image builder script that all magic for me for what I need in my own docker registry to keep things clear. If you see that image builder you would be amazed, trust me, making images for me is very easy now with all kinds of files/folders/etc for what I need there.

What I just did is build the same way without the -alpine part of the builder, I don’t know what the default image is what Caddy uses but I can look it up.

Without -alpine my image starts just fine.

Okay, then there’s no problem then?

1 Like

There is, the -alpine image/builder seems to be broken… ??

The default image is alpine (we don’t ship any other OS variant currently).

I’m not sure what you mean. It sounds like you have something that is working, so why not just use that?

Because I like to have things right. If I build using -alpine it doesn’t work, so the question is, why not ? Could it be that the -alpine image is broken during the build process @ Docker repo ?

Maybe you should check that image ?

Which tags have you tried, exactly?

-builder-alpine and -builder are exactly the same images (same hash, etc). See Docker

The only difference is that -alpine doesn’t exist for Windows images (because those aren’t Linux obviously).

-builder-alpine => gives me the known error as describes
-builder => works fine

And I’m building lots of different images this way without any issues at all.

How do you mean doesn’t exist for Windows images ? We are talking about linux/docker here ?

Yes, but Docker has Windows-native images (Docker on Windows can run Windows containers). Look at the link above to see the list of tags.

I don’t believe that. The problem must be elsewhere (in your build pipeline or config).

They’re literally identical images, which is proved by the hash of the image being the same.

For example:

Also see Docker

Yes it’s what wonders me as well, I only needed to remove the -alpine part of the image(tags) and it worked fine.

I also see a difference in size; 1MB to be precise.

I’m going to investigate what goes/went wrong and report back after checking used source images!

Thanks so far!

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.