Permission error / Access Denied - Bookworm

Dear Forum,

1. The problem I’m having:

I’ve installed an acoustic analyzing program, using Caddy as webserver. All programs and scripts get installed from an installer script, on a fresh Raspberry Pi.

On my Pi4 (Bullseye), installation worked well, and the Caddy is working well.
On my Pi5 (Bookworm), I keep on getting an error, and I assume this is related to Permission settings:

2. Error messages and/or full log output:

Get this when trying to access the site:
403 Forbidden stat /home/pi/BirdSongs/Extracted: permission denied fileserver.(*FileServer).ServeHTTP (staticfiles.go:282) rh2gy8qyf

curl -v 127.0.0.1:80
*   Trying 127.0.0.1:80...
* Connected to 127.0.0.1 (127.0.0.1) port 80 (#0)
> GET / HTTP/1.1
> Host: 127.0.0.1
> User-Agent: curl/7.88.1
> Accept: */*
>
< HTTP/1.1 403 Forbidden
< Content-Type: text/plain; charset=utf-8
< Server: Caddy
< Date: Fri, 15 Dec 2023 21:04:26 GMT
< Content-Length: 132
<
* Connection #0 to host 127.0.0.1 left intact

3. Caddy version:

v2.7.6

4. How I installed and ran Caddy:

Caddy got installed as part of an installation script, with command:
apt install caddy

a. System environment:

Raspberry Pi5 - 4Gb

No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 12 (bookworm)
Release:        12
Codename:       bookworm

b. Command:

running Caddy as systemd:

pi:~/BirdNET-Pi$ sudo systemctl status caddy
● caddy.service - Caddy
     Loaded: loaded (/lib/systemd/system/caddy.service; enabled; preset: enabled)
    Drop-In: /etc/systemd/system/caddy.service.d
             └─override.conf
     Active: active (running) since Thu 2023-12-14 19:29:16 GMT; 1 day 1h ago
       Docs: https://caddyserver.com/docs/
    Process: 510149 ExecReload=/usr/bin/caddy reload --config /etc/caddy/Caddyfile --force (code=exited, status=0/SUCCESS)
   Main PID: 304676 (caddy)
      Tasks: 10 (limit: 4453)
        CPU: 4.506s
     CGroup: /system.slice/caddy.service
             └─304676 /usr/bin/caddy run --environ --config /etc/caddy/Caddyfile

Dec 15 14:05:01 pi caddy[304676]: 2023-12-15 14:05:01.393891921 +0000 GMT m=+66944.902621939 write error: write /var/log/caddy/access.log: no space left on>
Dec 15 14:10:01 pi caddy[304676]: 2023-12-15 14:10:01.440447771 +0000 GMT m=+67244.949177826 write error: write /var/log/caddy/access.log: no space left on>
Dec 15 14:15:01 pi caddy[304676]: 2023-12-15 14:15:01.47870128 +0000 GMT m=+67544.987431335 write error: write /var/log/caddy/access.log: no space left on >
Dec 15 14:20:01 pi caddy[304676]: 2023-12-15 14:20:01.713859432 +0000 GMT m=+67845.222589450 write error: write /var/log/caddy/access.log: no space left on>
Dec 15 14:25:01 pi caddy[304676]: 2023-12-15 14:25:01.758542744 +0000 GMT m=+68145.267272762 write error: write /var/log/caddy/access.log: no space left on>
Dec 15 17:50:01 pi caddy[304676]: 2023-12-15 17:50:01.29673623 +0000 GMT m=+80444.805466248 write error: write /var/log/caddy/access.log: no space left on >
Dec 15 17:55:01 pi caddy[304676]: 2023-12-15 17:55:01.333213554 +0000 GMT m=+80744.841943572 write error: write /var/log/caddy/access.log: no space left on>
Dec 15 18:00:01 pi caddy[304676]: 2023-12-15 18:00:01.363707091 +0000 GMT m=+81044.872437109 write error: write /var/log/caddy/access.log: no space left on>
Dec 15 18:05:01 pi caddy[304676]: 2023-12-15 18:05:01.396072984 +0000 GMT m=+81344.904803002 write error: write /var/log/caddy/access.log: no space left on>
Dec 15 18:10:01 pi caddy[304676]: 2023-12-15 18:10:01.434739864 +0000 GMT m=+81644.943469882 write error: write /var/log/caddy/access.log: no space left on>

c. Service/unit/compose file:

d. My complete Caddy config:

http:// {
        root * /home/pi/BirdSongs/Extracted
        file_server browse
        handle_errors {
                respond "{err.status_code} {err.status_text} {err.message} {err.trace} {err.id}"
        }
        log {
                output file /var/log/caddy/access.log
        }
        handle /By_Date/* {
                file_server browse
        }
        handle /Charts/* {
                file_server browse
        }
        reverse_proxy /stream localhost:8000
        php_fastcgi unix//run/php/php8.2-fpm.sock
        reverse_proxy /log* localhost:8080
        reverse_proxy /stats* localhost:8501
        reverse_proxy /terminal* localhost:8888
}

5. Links to relevant resources:

6. What I’ve tried:

  1. I noticed that Permissions in my Home folder were different on my Pi5 (Bookworm) vs my Pi4 (Bullseye), and gave WRITE access to the Group in all files in my Home folder (chmod 666)

  2. I’ve change already the correct php version in the Caddyfile to php8.2 (this was at php7.4 in the installation, but the 8.2 was installed)

  3. I’ve noticed that on the Pi5 (Bookworm): Apache got installed, whilst on the Pi4 (Bullseye) and with the same installation script, it was not installed. I’ve stopped appache service

  4. not sure if relevant, but get different output for this:µ
    on the Pi4 (bullseye):

pibirdnet:~/BirdNET-Pi$ getcap -r / 2>/dev/null
pibirdnet:~/BirdNET-Pi$

on the Pi5 (Bookworm):

pi:~/BirdNET-Pi$ getcap -r / 2>/dev/null
/usr/lib/aarch64-linux-gnu/gstreamer1.0/gstreamer-1.0/gst-ptp-helper cap_net_bind_service,cap_net_admin=ep
pi:~/BirdNET-Pi$

So, I think the issue is related to Permissions which are not correct (line 282 in caddy/modules/caddyhttp/fileserver/staticfiles.go at master · caddyserver/caddy · GitHub), but really don’t know where to start…

thanks for any help on this issue!

Caddy runs as the caddy user, which doesn’t have access to /home.

Move your files elsewhere, like /srv or /var/www/html and make sure the caddy user has access to the files there.

You should probably turn off access logging, looks like storage was filled up. Access logs are not that useful unless you’re actively debugging, so if you’re on a storage constrained device you should leave it off.

thanks for this.

On the reply, two points:

  1. on my Pi4 (bullseye), this setup is working, thus having all files in that folder under home/pi. This is the reason why I gave additional WRITE access rights to the Group users.
  2. storage: yes and solved, but not solving the problem :wink:

I don’t understand what you mean. Please explain in more detail.

Reminder that on unix systems, for a user to be able to access a file, it needs executable access on every directory that is a parent to the target file. Users typically don’t have executable permission on /home so that they cannot see other users on the system.

This means that the caddy user won’t be able to see anything inside of /home even if you give permissions to a subdirectory. That’s why you should put your files in /srv or /var/www/html which does not have this problem because you have more control over the permissions of those locations without having unintended sideeffects (you should not modify permissions of /home, that’s dangerous).

1 Like

but then, why does this configuration work on my Pi with bullseye?

I have exactly the same CaddyFile, and the the folders are placed in the same location /home/pi/…
(there are additional lines, but those should get written with passwords (via the webpage)

on my Pi4, I have this CaddyFile:


> http://  {
>         root * /home/pi/BirdSongs/Extracted
>         file_server browse
>         handle /By_Date/* {
>                 file_server browse
>         }
>         handle /Charts/* {
>                 file_server browse
>         }
>         basicauth /views.php?view=File* {
>                 birdnet $2a$14$qqDGOZ.LZG/4/j0RdHmNPud4o/1oAwEMGyqLTID7wOYyVF..IZddi
>         }
>         basicauth /Processed* {
>                 birdnet $2a$14$qqDGOZ.LZG/4/j0RdHmNPud4o/1oAwEMGyqLTID7wOYyVF..IZddi
>         }
>         basicauth /scripts* {
>                 birdnet $2a$14$qqDGOZ.LZG/4/j0RdHmNPud4o/1oAwEMGyqLTID7wOYyVF..IZddi
>         }
>         basicauth /stream {
>                 birdnet $2a$14$qqDGOZ.LZG/4/j0RdHmNPud4o/1oAwEMGyqLTID7wOYyVF..IZddi
>         }
>         basicauth /phpsysinfo* {
>                 birdnet $2a$14$qqDGOZ.LZG/4/j0RdHmNPud4o/1oAwEMGyqLTID7wOYyVF..IZddi
>         }
>         basicauth /terminal* {
>                 birdnet $2a$14$qqDGOZ.LZG/4/j0RdHmNPud4o/1oAwEMGyqLTID7wOYyVF..IZddi
>         }
>         reverse_proxy /stream localhost:8000
>         php_fastcgi unix//run/php/php7.4-fpm.sock
>         reverse_proxy /log* localhost:8080
>         reverse_proxy /stats* localhost:8501
>         reverse_proxy /terminal* localhost:8888
> }

Accessing here on the Pi4 (Bullseye), gives:

curl -v 127.0.0.1:80
*   Trying 127.0.0.1:80...
* Connected to 127.0.0.1 (127.0.0.1) port 80 (#0)
> GET / HTTP/1.1
> Host: 127.0.0.1
> User-Agent: curl/7.74.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Content-Type: text/html; charset=UTF-8
< Server: Caddy
< Date: Thu, 07 Dec 2023 18:31:38 GMT
< Content-Length: 716

Like I said, has to do with unix permissions. If your old system had overly permissive permissions, then it might have worked (but it’s incorrect).

So, indeed a chmod 7777 to the full /home/pi/ folder and subfolders resolves this, but obviously also comes with exposure…

Will check if/how I can move everything to /var/www

thanks,
Pieter

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