Unable to access root path for a 777 path

Hi, I’m completely stumped. I’ve been searching for a fix for two days now.
My Caddy service can’t access my root path.

sudo systemctl -l status caddy.service

gives

● caddy.service - Caddy HTTP/2 web server
   Loaded: loaded (/etc/systemd/system/caddy.service; enabled)
   Active: failed (Result: exit-code) since Tue 2018-01-30 09:45:22 UTC; 13s ago
 Docs: https://caddyserver.com/docs
 Main PID: 16326 (code=exited, status=1/FAILURE)

Jan 30 09:45:22 Cloudberry systemd[1]: Started Caddy HTTP/2 web server.
Jan 30 09:45:22 Cloudberry caddy[16326]: /etc/caddy/Caddyfile:2 - Error during parsing: Unable to access root path '/media/cloak/www/': stat /media/cloak/www/: permission denied
Jan 30 09:45:22 Cloudberry systemd[1]: caddy.service: main process exited, code=exited, status=1/FAILURE
Jan 30 09:45:22 Cloudberry systemd[1]: Unit caddy.service entered failed state.

Caddyfile:

example.com {
    root /media/cloak/www/
    gzip

    proxy /home localhost:8096 {
        transparent
    }
}

caddy.service:

[Unit]
Description=Caddy HTTP/2 web server
Documentation=https://caddyserver.com/docs
After=network-online.target
Wants=network-online.target systemd-networkd-wait-online.service

[Service]
Restart=on-abnormal

; User and group the process will run as.
User=www-data
Group=www-data

; Letsencrypt-issued certificates will be written to this directory.
Environment=CADDYPATH=/etc/ssl/caddy

; Always set "-root" to something safe in case it gets forgotten in the Caddyfile.
ExecStart=/usr/local/bin/caddy -log stdout -agree=true -conf=/etc/caddy/Caddyfile -root=/var/tmp
ExecReload=/bin/kill -USR1 $MAINPID

; Use graceful shutdown with a reasonable timeout
KillMode=mixed
KillSignal=SIGQUIT
TimeoutStopSec=5s

; Limit the number of file descriptors; see `man systemd.exec` for more limit settings.
LimitNOFILE=1048576
; Unmodified caddy is not expected to use more than that.
LimitNPROC=512

; Use private /tmp and /var/tmp, which are discarded after caddy stops.
#PrivateTmp=true
; Use a minimal /dev
#PrivateDevices=true
; Hide /home, /root, and /run/user. Nobody will steal your SSH-keys.
ProtectHome=true
; Make /usr, /boot, /etc and possibly some more folders read-only.
ProtectSystem=full
;  ^   except /etc/ssl/caddy, because we want Letsencrypt-certificates there.
;   This merely retains r/w access rights, it does not add any new. Must still be writable on the host!
ReadWriteDirectories=/etc/ssl/caddy

; The following additional security directives only work with systemd v229 or later.
; They further retrict privileges that can be gained by caddy. Uncomment if you like.
; Note that you may have to add capabilities required by any plugins in use.
;CapabilityBoundingSet=CAP_NET_BIND_SERVICE
;AmbientCapabilities=CAP_NET_BIND_SERVICE

[Install]
WantedBy=multi-user.target

Starting caddy as my user is no problem it’s only the service that fails.
The www folder is owned by www-data and I’ve given it full 777 permissions as a test case, still 403 for every page.

You should set the folder to 755 first, 777 is nasty. Set files to 644. It’s dangerous to run caddy with sudo rights too. You have a couple options, here are two that should work:

  1. Set up group permissions so that your actual user has permission to the folders/files
  2. Run Caddy from the www.data user
1 Like

But surely the caddy service is running as www-data, as stated in the caddy.service file, regardles of what level systemctl is executed at?

I avoid systemd wherever possible, so I’m taking a stab in the dark, but can the process even access /media with all that sandboxing configuration?

Might be worth trying to add your web root to ReadWriteDirectories?

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