Dockerised Nextcloud+Apache web server behind a Caddy reverse proxy

1. Caddy version (caddy version):

v2.1.1 h1:X9k1+ehZPYYrSqBvf/ocUgdLSRIuiNiMo7CvyGUQKeA=

2. How I run Caddy:

a. System environment:

FreeNAS 11.3-U4.1

b. Command:

service caddy start

c. Service/unit/compose file:

Not applicable

d. My complete Caddyfile or JSON config:

See below.

3. The problem I’m having:

See below.

4. Error messages and/or full log output:

See below.

5. What I already tried:

See below.

6. Links to relevant resources:

See below.

7. Below :grinning:

Rather than fill in the proforma, I thought it better to tell the story in chronological order. It will make more sense that way.

I’ve got two instances of Nextcloud that I’m testing. The first is in a FreeNAS jail and the second in a Docker container running on a Ubuntu 18.4.04 virtual machine also on FreeNAS. At this point, the key difference between the jail and the container is that in the jail, all the Nextcloud dependencies have to be considered, whereas, in the containerised version, all Nextcloud dependencies are already taken of, so it’s almost plug-n-play.

Both instances are unsecured. They’re accessible via http. A separate Caddy reverse proxy handles TLS termination for the Nextcloud instances.

Nextcloud in a FreeNAS jail

Caddy was selected for the Nextcloud web server. The Caddyfile used was based on the Caddy code block result from the thread Help to migrate Caddyfile V1 to V2 for Nextcloud.

        # debug
}, {
        root * /usr/local/www/nextcloud
        log {
                output file /var/log/
                format single_field common_log

        php_fastcgi {
                env front_controller_active true

        redir /.well-known/carddav /remote.php/dav 301
        redir /.well-known/caldav /remote.php/dav 301

        # .htaccess / data / config / ... shouldn't be accessible from outside
        @forbidden {
                path /.htaccess
                path /data/*
                path /config/*
                path /db_structure
                path /.xml
                path /README
                path /3rdparty/*
                path /lib/*
                path /templates/*
                path /occ
                path /console.php

        respond @forbidden 404

When the unsecured Nextcloud instance is accessed and checked for warnings, this is what I see.

This is expected for an unsecured Nextcloud instance.

Now when I place this Nextcloud instance behind the Caddy reverse proxy using the Caddyfile block below…

# Nextcloud - FreeNAS Jail {
  encode gzip
  import dnschallenge


…the unsecured access warnings disappear.

This also is an expected result.

Nextcloud in a Docker Container

An official version of the Nextcloud container from Docker Hub was used. It uses an Apache webserver. When this unsecured Nextcloud instance is accessed, I get the same result as for the unsecured jail instance of Nextcloud. So far, so good.

The difference comes about when I place this Nextcloud instance behind the Caddy reverse proxy using a very similar Caddyfile code block:

# Nextcloud in a Docker Container {
  encode gzip
  import dnschallenge


These are the warnings I see:

It’s close, but not quite the same. There are now warnings about the web server (I’m assuming the Apache web server) not being properly set up to handle caldav and carddav. The warnings refers me to this documentation. I check the Apache web server and I can see that it’s already configured for service discovery.

<IfModule mod_rewrite.c>
  RewriteEngine on
  RewriteCond %{HTTP_USER_AGENT} DavClnt
  RewriteRule ^$ /remote.php/webdav/ [L,R=302]
  RewriteRule .* - [env=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
  RewriteRule ^\.well-known/host-meta /public.php?service=host-meta [QSA,L]
  RewriteRule ^\.well-known/host-meta\.json /public.php?service=host-meta-json [QSA,L]
  RewriteRule ^\.well-known/webfinger /public.php?service=webfinger [QSA,L]
  RewriteRule ^\.well-known/nodeinfo /public.php?service=nodeinfo [QSA,L]
  RewriteRule ^\.well-known/carddav /remote.php/dav/ [R=301,L]
  RewriteRule ^\.well-known/caldav /remote.php/dav/ [R=301,L]
  RewriteRule ^remote/(.*) remote.php [QSA,L]
  RewriteRule ^(?:build|tests|config|lib|3rdparty|templates)/.* - [R=404,L]
  RewriteCond %{REQUEST_URI} !^/\.well-known/(acme-challenge|pki-validation)/.*
  RewriteRule ^(?:\.|autotest|occ|issue|indie|db_|console).* - [R=404,L]

I enter into a browser and it does get redirected to I start to get a little suspicious. I begin to think that maybe these are phantom warnings. Still, it’s disconcerting to see them there.

So, I go searching and I get to this wonderful Nextcloud forum thread HowTo: Ubuntu + Docker + Nextcloud + Talk + Collabora, which I’ve since closely referred to when setting up the Docker version of Nextcloud. In this instance, the writer has used an Apache reverse proxy. What caught my attention were the following lines in one of the reverse proxy configuration files:

  RewriteRule ^/\.well-known/carddav http://%{SERVER_NAME}/remote.php/dav/ [R=301,L]
  RewriteRule ^/\.well-known/caldav http://%{SERVER_NAME}/remote.php/dav/ [R=301,L]

My question (after all that!) is 'Do I need to do something similar in the Caddyfile code block I use to interact with the Docker version of Nextcloud?

i have a similar installation (nextcloud +apache in docker container, plus caddy as reverse proxy).

i do have the two redir rules in my Caddyfile (outside of reverse_proxy):

redir /.well-known/carddav /remote.php/carddav 301
redir /.well-known/caldav /remote.php/caldav 301

and i get no warnings in the nextcloud admin pages
(i also have this header setting:

header Strict-Transport-Security Strict-Transport-Security "max-age=15768000; includeSubDomains; p

), outside of the reverse_proxy
it works since a few months.

1 Like

That did the trick. Thanks @jok! My working Caddyfile code block is:

# Nextcloud in a Docker Container {
  encode gzip
  import dnschallenge


  redir /.well-known/carddav /remote.php/carddav 301
  redir /.well-known/caldav /remote.php/caldav 301

Yes, I’m aware of the HSTS issue, but as I’m currently experimenting with various scenarios by building and pulling down Nextcloud instances, I’m happy to let that slip by for the moment.

1 Like

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