1. The problem I’m having:
TL:DR; We are seeing some sub-directories and files created in a PHP CMS’s storage/runtime/compiled_templates directory owned by the caddy user, but the CMS then does not have permission to access those files (which causes problems).
We can’t work out how to solve this “properly”.
In the screenshot, the CMS trying to use the 9f directory throws permission errors.
The temporary solution is to run a fix-permissions.sh script which does this:
sudo chown -R ${BASH_USER}:www-data .
sudo find . -type d -exec chmod ug+rwx {} \;
sudo find . -type f -exec chmod ug+rw {} \;
sudo find . -type d -exec chmod g+s {} \;
BASH_USER is admin, but does also work as www-data.
This solves things until the CMS next generates a new directory or file in there, and then… that seems to be owned by the caddy user again.
2. Error messages and/or full log output:
This isn’t strictly a Caddy error, more a “we have some configuration issue we can’t work out how to solve, and hope someone here has some insight”.
3. Caddy version:
v2.7.6 h1:w0NymbG2m9PcvKWsrXO6EEkY9Ru4FJK8uQbYcev1p3A=
4. How I installed and ran Caddy:
Via the official guide, adding a Debian repo, using apt.
a. System environment:
Debian Linux 12, PHP 8.2, Systemd.
Further details:
The system has a “limited user” called admin we use instead of root.
We created a directory out of which to serve multiple sites as follows:
sudo mkdir /websites
sudo chown admin:www-data websites
The Caddyfile is symlinked from in there:
cd /websites
ln -s /etc/caddy/Caddyfile Caddyfile
sudo chown admin:admin /etc/caddy/Caddyfile
All sites are checkout out as sub-directories inside that /websites, and all folders and files are owned by admin:www-data (except the Caddyfile itself).
PHP was installed via apt and we are using it via FPM.
Configs for Caddy and PHP are essentially default, but to clarify:
/etc/php/8.2/fpm/pool.d
user = www-data
group = www-data
/lib/systemd/system/caddy.service
User=caddy
Group=caddy
System users and the groups they belong to:
# groups caddy
caddy : caddy www-data
# groups admin
admin : admin sudo users
b. Command:
It just runs via systemd on system start.
c. Service/unit/compose file:
n/a
d. My complete Caddy config:
# Snippets (see: https://caddyserver.com/docs/caddyfile/concepts)
(staticFileCache) {
@static {
file
path *.ico *.css *.js *.gif *.jpg *.jpeg *.webp *.png *.svg *.woff2
}
header @static Cache-Control max-age=5184000
}
(blitzNoQueryString) {
@blitzCache {
method GET
not expression {query} != ''
}
route @blitzCache {
try_files /cache/blitz/{host}{uri}/index.html {path} {path}/index.php?{query}
}
}
(wordpressBruteForce) {
@blockList {
path /wp-*
}
abort @blockList
@block2 {
path *wp-includes*
}
abort @block2
}
thewebsite.url {
root * /websites/thewebsite/public
encode gzip
file_server
templates {
between <!--#caddy -->
}
import staticFileCache
import wordpressBruteForce
import blitzNoQueryString
log {
output file /websites/_logs/thewebsite.log
}
php_fastcgi unix//run/php/php8.2-fpm.sock
}
5. Links to relevant resources:
We’re using CraftCMS - which does have a CLI so I’m also asking over there to see if there’s some mechanism whereby this might happen because of the CLI functionality and how that might be being called in some manner that results in caddy being the user.
We’re seeing this on a small handful of projects, but its one of those things that shows up only when we’re on production, and the only reason we’re noticing it is because the CMS is failing to send out emails when visitors fill out forms - and most projects don’t have that functionality.