Yep, the command is caddy validate. But it won’t tell you any more than just running Caddy does, because that step is implicit when running.
That looks like an oversight. It should probably attempt to write then read from a dummy in the configured storage location at startup. /cc @matt we should port the checkStorage from certmagic to Caddy’s startup.
Caddy isn’t falling back to the default folder. It’s just failing to write things to storage. If Caddy did start up and storage suddenly started failing, then shutting down is worse than continuing to run with a potentially working config.
I agree Caddy probably shouldn’t have started up in this case though.
It is obvious though, the logs pretty clearly say so. No guessing involved. Checking the logs should always be the first thing to do if something’s not working.
Like I said earlier though, Caddy runs as the user called caddy, not as www-data. So the users don’t match in those permissions. Either give the caddy user ownership of those (like caddy:root or something) or give the www-data group ownership (like www-data:www-data or something) since the caddy user is part of the www-data group.
If all that doesn’t work, then your problem is elsewhere, likely with your EFS config.
WOW, so that was absolutely a strange issue and I think it’s something related to the CaddyServer service.
Because I’m not an expert I took someone to help me with that, and he couldn’t solve the issue, he just tried everything.
In the end, he changed the folder from “/etc/caddy_log” to “/var/caddy_log” and everything is working.
We checked further and we couldn’t save anything under “/etc…” and others folders like “/var…” working just fine.
If we stop run Caddy as a service the folder “/etc…” worked.
I don’t know where is the problem but I hope this solution will help others.
Aaah, right. I keep forgetting about that. Thanks @Mohammed90 for the reminder, and sorry everyone else for it taking longer than necessary to find the issue