Checking User/Group is set up properly?

1. The problem I’m having:

I need to properly understand the user/group that Caddy is running as, and more crucially - what user/group I should be setting the custom web directory as so that things work properly without permission errors given my setup.

I SSH onto a server as the user webadmin and that user is the owner of the directory all websites are served from (because that owner is also the one with access to private GitHub repositories, which is where sites are pulled from to run on the server), how do I correctly ensure the right owner/permissions?

At the moment I’ve manually run a chown -R webadmin:www-data /websites which seems to work, but some files (such as log files) can end up owned as caddy:caddy inside there, and while it works after changing permissions like that, some generated files end up with permission errors later down the line.

I also want to set up a SystemD Daemon for a PHP application, and it needs to run as the same user and group as Caddy itself. Their examples are www-data, and I want to know how to be sure I’m setting this correctly for Caddy, as I’m pretty sure Caddy is not running as www-data:www-data.

# /etc/systemd/system/craft-queue-worker@.service
# Note the @ in the filename above!

[Unit]
Description=Craft CMS Queue %i
After=network.target
After=mysql.service
Requires=mysql.service
# (...or postgresql.service!)

[Service]
# User + Group should agree with HTTP processes:
User=www-data
Group=www-data
ExecStart=/usr/bin/php /var/www/craft queue/listen --verbose=1 --color=0
# Only restart after unexpected failures:
Restart=on-failure
# Extend time between restart attempts after a failure:
RestartSec=120

[Install]
WantedBy=multi-user.target

Thanks for your time! I think I mostly understand things, but I’m wanting to check before I try the Daemon.

2. Error messages and/or full log output:

No errors yet, just checking I don’t screw up first!

3. Caddy version:

v2.7.6 h1:w0NymbG2m9PcvKWsrXO6EEkY9Ru4FJK8uQbYcev1p3A=

4. How I installed and ran Caddy:

Followed the official guide.

sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install caddy git

a. System environment:

Debian 12

d. My complete Caddy config:

Not relevent

5. Links to relevant resources:

https://craftcms.com/docs/4.x/queue.html#daemon

Caddy does run as the caddy user (when using our systemd service), but we also add the caddy user to the www-data group on package installation since lots of stuff like PHP tend to use that user/group. So having files owned by caddy or group-owned by www-data should be what you need.

1 Like

Thanks Francis, appreciate it. I think I need to look into ACL’s to make sure that all “generated” files and directories in there end up group-owned by www-data too, as I think that’s why I sometimes have some issues with permissions that need me to re-run the chown. I don’t think that’s a Caddy thing per-se tho.

1 Like

Yeah, not a Caddy thing, that’s a dev processes problem on your end :+1:

1 Like

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