Can I use a symbolic link to the Caddyfile?

I’m trying to create a script to launch a new server with my configuration, including Caddy of course. And I also wish to keep the configuration outside the server, to edit it with my computer for instance and then push the changes on the server.

To that end, I wanted to create symbolic links between the configuration folder (for instance stored in the home folder) and the Caddyfile, store in /etc/caddy (I followed this guide). Whenever I want to make changes to this file, I push and pull the modification through git.

Unfortunately, I can’t launch the caddy service using this symlinked file. When I try to start the service, I have this error :

Jan 26 12:24:49 voiretmanger caddy[19295]: 2018/01/26 12:24:49 loading Caddyfile via flag: open /etc/caddy/Caddyfile: permission denied

I made sure the file belonged to the correct user and group and had the correct permissions, but unfortunately, the symbolic link itself is root, so I guess it’s the cause of the problem.

Is there a better way to do what I want ? Or a way to convince Caddy to use my linked Caddyfile ?

EDIT : if needed, all the configuration is detailed here : at main · nicolinuxfr/ · GitHub

Strange to see link permissions as an issue; link permissions are normally useless, and a file accessed through a symbolic link should instead check the permissions of its target file.

Few thoughts:

If /etc and /home are on the same disk, you could consider using a hard link instead of a symbolic link, which might have better results.

You could also consider pointing -conf directly at the Caddyfile in /etc/caddy instead of linking it to a home folder and then loading it from there.

I ran into a similar issue. I had my git checkout at “/root/foo”, and so the symlink was

/etc/caddy/Caddyfile -> /root/foo/Caddyfile

and I was getting the same “permission denied” error. It was not a caddy-specific problem, I was getting a permission error also when doing

sudo -u caddy cat /etc/caddy/Caddyfile

I think the problem was that “/root” directory doesn’t have group or public read permission (even though some directories and files inside it do). I moved “foo” outside of “/root/” and it worked afterwards.