That was strange. The Caddyfile is owned by root, the caddy.service file is owned by root, and the service is executed and run as root. So it wasn’t a permission issue.

Let’s see what systemd has to say for itself.

I ran the command journalctl -u caddy --no-pager | less, and that is when I saw this:

caddy[736]: run: reading config file: open /the/path/to/Caddyfile: permission denied

So it was a permission issue after all. But how? Is being root not enough?

I furiously started searching the web and eventually stumbled upon this StackOverflow post, which suggested that SELinux could cause this type of behaviour.

I temporarily disabled SELinux with sudo setenforce Permissive to see if it would fix my issue ‒ and it did. Cool, but why would SELinux cause the issue in the first place? What didn’t it like about my caddy.service file?

To find out, I started with the semanage fcontext --list command. This is when I realised that I was storing my Caddyfile in a directory that SELinux didn’t approve of. So my final solution was just to move it to a directory that SELinux was happy with. The last thing I needed to do was update the caddy.service file to point to the new location of the Caddyfile and restart the service.