File Browser: Configuring Caddy Auth Header

1. The problem I’m having:

I’m trying to configure caddy reverse proxy for File Browser. I’m using docker-compose and Caddy. I’m able to access the application via local IP and port but Caddy continuously times out when trying to acquire a certificate. Judging by the (albeit vague) documentation I need to add a header to the Caddyfile for this application. It provides the following template as an example:

filebrowser config set --auth.method=proxy --auth.header=X-My-Header

X-My-Header is supposed to be where a proxy header specifying the user is pasted. I’m not sure what this even means.

I assume it should be inserted in the Caddyfile where the commented line is located. I have a similar setup for nextcloud but that solution is not working in this instance.

 filebrowser.{$MY_DOMAIN} {
     reverse_proxy filebrowser:8024
#    filebrowser config set --auth.method=proxy --auth.header=Remote-User

After reviewing the Caddy documentation I think I’m out of my depth on this one. I host a number of applications with this Caddy configuration and with the exception of the Nextcloud instance mentioned earlier, none of them require a proxy header.

2. Error messages and/or full log output:

{"level":"error","ts":1683260464.1862993,"logger":"http.acme_client","msg":"validating authorization","identifier":"","problem":{"type":"urn:ietf:params:acme:error:unauthorized","title":"","detail":" Invalid response from 404","instance":"","subproblems":[]},"order":"","attempt":2,"max_attempts":3}
{"level":"error","ts":1683260464.1863458,"logger":"tls.obtain","msg":"could not get certificate from issuer","identifier":"","issuer":"","error":"HTTP 403 urn:ietf:params:acme:error:unauthorized - Invalid response from 404"}
{"level":"error","ts":1683260464.186458,"logger":"tls.obtain","msg":"will retry","error":"[] Obtain: [] solving challenge: [] authorization failed: HTTP 403 urn:ietf:params:acme:error:unauthorized - Invalid response from 404 (ca=","attempt":1,"retrying_in":60,"elapsed":22.885142679,"max_duration":2592000}

3. Caddy version:


4. How I installed and ran Caddy:

I am using the official caddy docker image

a. System environment:

Synology NAS 918+

b. Command:

docker-compose up -d caddy filebrowser
docker logs caddy

c. Service/unit/compose file:

version: "3.7"
  image: caddy
  container_name: caddy
  hostname: caddy
  restart: unless-stopped
    - "780:80"
    - "7443:443"
    - "32400:32400"
    - ./Caddyfile:/etc/caddy/Caddyfile:ro
    - ./caddy/data:/data
    - ./caddy/config:/config

  image: filebrowser/filebrowser
  container_name: filebrowser
  user: 1026:100
    - 8024:8024
   - /volume1/data/docker/filebrowser/config/filebrowser.db:/database.db
   - /volume1/data/docker/filebrowser/config/.filebrowser.json:/.filebrowser.json
   - /volume1/data:/srv
  restart: unless-stopped
   - no-new-privileges:true


d. My complete Caddy config:

 filebrowser.{$MY_DOMAIN} {
     reverse_proxy filebrowser:8024
     header Strict-Transport-Security max-age=31536000;
#	 filebrowser config set --auth.method=proxy --auth.header=Remote-User

5. Links to relevant resources:

I used this video to get it installed

AfterwardsI ended up having to add a .json file to get it to work. It has this configuration…

  "port": 8024,
  "address": "",
  "database": "/database.db",
  "scope": "/srv",
  "allowCommands": true,
  "allowEdit": true,
  "allowNew": true,
  "commands": []

Can you run this and show what you get?

curl -v

If you’re not seeing Server: Caddy, then Let’s Encrypt isn’t actually reaching your server.

Make sure DNS is correct, and make sure you don’t have something like Cloudflare in the way intercepting requests before they reach your server.

Edit: Oh, this is probably the issue:

You must make Caddy available on ports 80 and 443 to be able to get a certificate using the ACME HTTP or TLS-ALPN challenge. If that’s not possible, then you can use the DNS challenge (which involves making a custom build of Caddy – not too hard though, see the docs & forum wiki)

This is the response I receive:

GET /.well-known/acme-challenge/qt1ioqsE2P3oTdPMkqbXaxBmD8vj1yrZBqsodKt8fi0 HTTP/1.1
User-Agent: curl/7.79.1
Accept: */*

< HTTP/1.1 404 Not Found
< Server: nginx/1.14.2
< Date: Fri, 05 May 2023 13:29:09 GMT
< Content-Type: text/html
< Content-Length: 169
< Connection: keep-alive
<head><title>404 Not Found</title></head>
<body bgcolor="white">
<center><h1>404 Not Found</h1></center>

Regarding your comment about the caddy port configuration – I used this configuration to get around an issue with synology not allowing listening on port 80. I have ports 80/443 forwarded to 780 & 7443 respectively so that it can acquire certs. I have had ~10 containers using this configuration without issue for over a year.

Okay that’s fine re port config. As long as from the outside world 80 and 443 work.

But I think your DNS might be wrong, you’re hitting an nginx server, not Caddy.

I suspect it might have something to do with the Filebrowser json file. The documentation is sparse and I haven’t found example Caddyfile & json examples for Filebrowser/Caddy reverse proxy setup.

I don’t see what that has to do with anything. Filebrowser is written in Go, it has nothing to do with nginx. What I’m saying in your DNS is not pointing to the correct IP address, it’s sending requests to the wrong server.

1 Like

You nailed it. Stupid mistake. I didn’t point the DNS at my machine.

1 Like