Can´t get docker container running with TLS


I´m trying to get the docker container from abiosoft running.

For this i´m using OMV3 with its docker plugin.

This is how the container is configured

$ docker run -d \
-v home/caddy/Caddyfile:/etc \
-v home/certs:/root/.caddy \
-p 80:80 -p 443:443 \

So this is what it should look like… for those who are familar with the OMV plugin know that it looks a little different :wink:

For that Caddyfile the docker hub says the path inside the docker container should be /etc/Caddyfile which is now working … i´ve changed it to /etc and it works.

But now to my Problem… i want to use caddy as a reverse proxy using my dynamic dns “” - i´ve used this quite a while running let´s encrypt container with nginx from but wanted to try caddy because it looks very interesing to me.

My Caddyfile actually looks like this {


and this is what the logfile is showing…

2017/07/08 23:12:31 get directory at '': failed to get json "": Get x509: failed to load system roots and no roots provided

Activating privacy features…2017/07/08 23:12:32 get directory at ‘’: failed to get json “”: Get x509: failed to load system roots and no roots provided

When i turn tls off caddy is running well.

What also makes me wonder is the i bind mount the host path /home/caddy/certs to /root/.caddy and after starting the container i have a Certificates DIR on my Host in /home/Caddy/Caddyfile

Thanks in advance for any help! :wink:



You’re mounting home/caddy/Caddyfile to /etc. Perhaps try -v home/caddy/Caddyfile:/etc/Caddyfile.

I have to mount to /etc

Otherwise the caddyfile on my host won’t be found.

Very confusing…

I think you’re misunderstanding how volume mounting works.

You have a Caddyfile, but you’re mounting it to /etc. That means Docker is going to replace the directory /etc inside the container with a file called etc that has the contents of the Caddyfile.

The side effect of this is that you have no /etc directory - and the result is a laundry list of missing important configuration and system files. Among other things, this means you have no default (system) trusted root certificate authorities. Your container no longer has any reference by which to validate HTTPS certificates in the wild. It can’t even trust Letsencrypt’s website any more.

If you try @astei’s example instead, you’ll have your /etc folder still, but there will be a Caddyfile just inside, at /etc/Caddyfile.

When i try to bin mount /home/Caddy/Caddyfile to /etc/Caddyfile the container won´t even start.

Failed to execute command 'export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin; export LANG=C; docker run -d --restart=always -v /etc/localtime:/etc/localtime:ro --net=bridge -e PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" -v "/home/caddy/Caddyfile":"/etc/Caddyfile":rw "abiosoft/caddy:latest" 2>&1' with exit code '125': c9e00e9da4c83548381cfacb6c75584191614ae27262b765529900f9a2bb2963 docker: Error response from daemon: oci runtime error: container_linux.go:247: starting container process caused "process_linux.go:359: container init caused \"rootfs_linux.go:54: mounting \\\"/home/caddy/Caddyfile\\\" to rootfs \\\"/var/lib/docker/overlay2/761ee8aa765d062c870bc76ee483c7b55e0887f2f25ca6b88d026951f2124a6a/merged\\\" at \\\"/var/lib/docker/overlay2/761ee8aa765d062c870bc76ee483c7b55e0887f2f25ca6b88d026951f2124a6a/merged/etc/Caddyfile\\\" caused \\\"not a directory\\\"\"" : Are you trying to mount a directory onto a file (or vice-versa)? Check if the specified host path exists and is the expected type.

I´ve never had that much trouble with a container before…

Anyway i´ve pulled joshix/caddy container now and it works like a charm :wink:

On the host filesystem, is home/caddy/Caddyfile a file or a directory?

In the abiosoft/caddy container, /etc/Caddyfile is a file. If home/caddy/Caddyfile on the host is in fact a directory containing your Caddyfile inside it, and you tried to mount it to the location of a file, that would give you that error.

In fact, home/caddy/Caddyfile being a directory would explain how you were able to mount it to /etc without getting that error in the first place.

/home/caddy/Caddyfile is indeed a directory where the Caddyfile is in.

Ah. It should be the actual Caddyfile, not a directory.

Yep. Link the Caddyfile in directly, file to file. Assuming the host file is called Caddyfile inside the directory /home/caddy/Caddyfile, you’d want -v /home/caddy/Caddyfile/Caddyfile:/etc/Caddyfile, if you were still planning to use the abiosoft/caddy container.

Ok. Thx for the hint with mounting the file. Usually I’m mounting directories. Hehe

Let’s proxy now :wink:

Quick tips for Docker, because I suspect most of these apply here:

  • Don’t rely on the container runtime to create any directories. Their ownership might be off and don’t match the user caddy runs as.
  • Run containers with docker … run … --read-only --rm … <image>… and mount the directories to be served as well as /etc/caddy/ as volumes.
  • If caddy’s apparent user is ›root‹ (as seen from the host), then abandon the Docker image in favour of a different one. Never expose any process that runs as root to the net. (Or use Docker’s/Linux’ user mappings for the container, but that’s a different topic.)

… and, admittedly less important:

  • Start the Docker daemon with --userland-proxy=false, it’ll skip Docker’s proxy process(es) for better performance.

This sounds interesting, never looked too far into it before. Googling it resulted in some Docker docs referring to hairpin NAT (which I’m vaguely familiar with) and iptables (which I try to avoid at all costs because I don’t grok iptables, unfortunately).

Curious what other ramifications configuring the Docker daemon in this way might have?

I did understand the words you’ve mentioned, but not quite your question. (Furthermore: off-topic?)

I suggest giving this a try, and test if a container A talks to container B using the IP address of the host (use exposed ports, of course). Unless you run very old Linux it should work flawlessly.

Anyway, especially on brutally slow machines, and when using non-TCP protocols (currently UDP), the Docker proxy should be avoided. I’ve mentioned this repeatedly on chat and here, so nobody runs into this and opens an issue, only for us to find the proxy caused it.

1 Like

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