Nextcloud-AIO Docker container can't connect to domain behind Caddy

ℹ️ Support
, , , , ,
1

The Basics

  • Nextcloud Server version (e.g., 29.x.x):
    • AIO v 10.1.1
  • Operating system and version (e.g., Ubuntu 24.04):
    • OpenMediaVault 7.4.16-1 (Sandworm) - this is based on Debian 12 ( Bookworm)
  • Reverse proxy and version _(e.g. nginx 1.27.2)
    • Caddy 2.8.4-alpine
  • Is this the first time you’ve seen this error? (Yes / No):
    • Yes
  • When did this problem seem to first start?
    • While attempting to install and configure Nextcloud-AIO
  • Installation method (e.g. AlO, NCP, Bare Metal/Archive, etc.)
    • AIO
  • Are you using CloudfIare, mod_security, or similar? (Yes / No)
    • Cloudflare DNS, but no more

Summary of the issue you are facing:

I am attempting to set up Nextcloud-AIO on a subdomain on my home server (cloud.example.com). The server is running several services via Docker, and I am already running Caddy as a reverse proxy (using the caddy-docker-proxy plugin). Several other services are currently accessible via external URLs (test1.example.com is properly reverse-proxied).

Caddy is running as its own container, listening on ports 80 and 443. That single container provides reverse proxying to all my other services. Because of that, I am reluctant to make changes to the Caddy network unless I know it won’t have deleterious effects on my other services. This also means, unless I’m mistaken, that I can’t also spin up a new Caddy image within the Nextcloud-AIO container to listen on 80 and 443.

Using the docker-compose file below, I can start the Nextcloud-AIO container, and I can access the initial Nextcloud-AIO setup screen, but when I attempt to submit the domain defined in my Caddyfile (cloud.example.com), I get this error:

Domain does not point to this server or the reverse proxy is not configured correctly.

Steps to replicate it (hint: details matter!):

  1. Run the following Docker-Compose files.
  2. Navigate to https://<ip-address-of-server>:5050 to get a Nextcloud-AIO passphrase
  3. Enter the passphrase
  4. At https://<ip-address-of-server>:5050/containers, enter cloud.example.com (a subdomain of my home domain) under “New AIO Instance” and click “Submit domain”.

Configuration

Docker Compose Files

Nextcloud-AIO
services:
  nextcloud-aio-mastercontainer:
    image: nextcloud/all-in-one:latest
    init: true
    restart: always
    container_name: nextcloud-aio-mastercontainer
    volumes:
      - nextcloud_aio_mastercontainer:/mnt/docker-aio-config
      - /var/run/docker.sock:/var/run/docker.sock:ro
    ports:
      - 5050:8080 # changed this because something else was already running on 8080
    environment:
      - APACHE_PORT=11000
      - APACHE_IP_BINDING=127.0.0.1
      - NEXTCLOUD_DATADIR=<data directory>
      
volumes:
  nextcloud_aio_mastercontainer:
    name: nextcloud_aio_mastercontainer
Caddy
services:
  caddy:
    image: lucaslorentz/caddy-docker-proxy:2.8.4-alpine
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
      - "443:443/udp"
    environment:
      - CADDY_INGRESS_NETWORKS=caddy
    networks:
      - caddy
      - nextcloud-aio
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - ./Caddyfile:/etc/caddy/Caddyfile
      #- ./site:/srv
      - caddy_data:/data
      - caddy_config:/config

networks:
  caddy:
    external: true
  nextcloud-aio:
    external: true

volumes:
  caddy_data:
  caddy_config:

Caddyfile

https://cloud.example.com:443 {
        reverse_proxy localhost:11000 {
                transport http {
                        tls_insecure_skip_verify
                }
        }
}

Logs and Troubleshooting

  • I have followed most of the debugging steps on the guide.
  • I have tried changing my Caddyfile to reverse proxy the IP address of the server instead of localhost, and changed APACHE_IP_BINDING to 0.0.0.0 accordingly. No change.
  • Both these troubleshooting commands: docker exec -it caddy-caddy-1 nc -z localhost 11000; echo $? and docker exec -it caddy-caddy-1 nc -z 1 <server-ip-address> 11000; echo $? return 1.
  • My nextcloud-aio-mastercontainer logs display the following:
nextcloud-aio-mastercontainer  | NOTICE: PHP message: The response of the connection attempt to "https://cloud.example.com:443" was: 
nextcloud-aio-mastercontainer  | NOTICE: PHP message: Expected was: <long alphanumeric string>
nextcloud-aio-mastercontainer  | NOTICE: PHP message: The error message was: TLS connect error: error:0A000438:SSL routines::tlsv1 alert internal error

I am so very confused and don’t know what more to try or how to resolve this. All help is greatly appreciated.

2

I believe the part entitled " 1. On the same server in a Docker container" in the Configure the reverse proxy is the part you’re missing. Specifically item iii.

3

Thank you for the advice. This is the part you are looking at, correct?

Connect the reverse-proxy container to the nextcloud-aio network by specifying it as a secondary (external) network for the reverse proxy container. With this setup also, the reverse proxy can utilize Docker bridge network’s DNS name resolution to access nextcloud at http://nextcloud-aio-apache:$APACHE_PORT .

My understanding is that my Caddy container is configured to connect to the nextcloud-aio network given the Docker-Compose file I shared above; is there a step I’m missing in that?

Regarding http://nextcloud-aio-apache:$APACHE_PORT, I read that part of the documentation as saying this was an optional additional way for the Caddy reverse-proxy to reach Nextcloud. Should I instead be using http://nextcloud-aio-apache:$APACHE_PORT somewhere in my configuration?

Thank you for your assistance.

4

You can test connectivity from your reverse proxy container in the same manner as your earlier testing to find out e.g.

docker exec -it caddy-caddy-1 nc -z nextcloud-aio-apache 11000; echo $?

Note you may also need to change:


APACHE_IP_BINDING=0.0.0.0
1 Like
5

Thank you.

Whether APACHE_IP_BINDING is set to 127.0.0.1 or 0.0.0.0, I get success with the test command:

docker exec -it caddy-caddy-1 nc -z nextcloud-aio-apache 11000; echo $?

That yields 0.

However, regardless of what APACHE_IP_BINDING is set to, I’m still encountering the same issue described above: if I navigate in my browser to https://<ip-address-of-server>:5050/containers and enter cloud.example.com under “New AIO Instance”, I get the same error upon submission.

I’ve updated my Caddyfile:

https://cloud.example.com:443 {
        reverse_proxy nextcloud-aio-apache:11000 {
                transport http {
                        tls_insecure_skip_verify
                }
        }
}

Am I misunderstanding where I should be using http://nextcloud-aio-apache in my configuration?

6

I have determined through troubleshooting in a different forum that my Caddyfile was not being picked up by the Caddy plugin I was using. That plugin, caddy-docker-proxy, works by automatically generating a Caddyfile in-memory based on labels in Dockerfiles. I thought that it would just automatically pick up my Caddyfile and build on it, but I was mistaken.

The documentation here specifies an option:

--caddyfile-path string
        Path to a base Caddyfile that will be extended with Docker sites

which can also be set with the environment variable CADDY_DOCKER_CADDYFILE_PATH=<string>.

So I updated my Docker Compose file for Caddy:

# unchanged sections above omitted
    environment:
      - CADDY_INGRESS_NETWORKS=caddy,nextcloud-aio
      - CADDY_DOCKER_CADDYFILE_PATH=/etc/caddy/Caddyfile # I think this is a path inside the container?
# unchanged sections below omitted

This points, I think, to the Caddyfile that the container can access at /etc/caddy/Caddyfile, which if I’ve done my volume mapping correctly, should be where I have it located on my filesystem.

So I restarted the Caddy container with this new compose file, and… nothing. Nextcloud-AIO won’t connect tocloud.example.com.

Well, almost nothing. The debug global option I had set in the Caddyfile (not noted in this thread) does seem to be registered now where it did not previously; my logs for Caddy now contain lots of entries at the debug level.

For the sake of starting with what is recommended by the installation guide, now that the Caddyfile is being respected, I’ve returned the Caddyfile configuration to:

https://cloud.example.com:443 {
        reverse_proxy localhost:11000 {
                transport http {
                        tls_insecure_skip_verify
                }
        }
}

and this Nextcloud-AIO environment variable:

      - APACHE_IP_BINDING=127.0.0.1

I restarted the containers, but of course, our old refrain: still no change.

This from the logs is interesting to me:

{"resumed":false,"version":772,"cipher_suite":4865,"proto":"","server_name":"cloud.example.com"}},"error":"tls: first record does not look like a TLS handshake"}
caddy-1  | {"level":"error","ts":1736915663.03697,"logger":"http.log.error","msg":"tls: first record does not look like a TLS handshake","request": {"remote_ip":"[MY PUBLIC IP]","remote_port":"49670","proto":"HTTP/1.1","method":"GET","host":"cloud.example.com","uri":"/nextcloud/status.php","headers":{"Connection":["Keep-Alive"],"Accept-Language":["en-US,*"],"Authorization":[],"User-Agent":["Mozilla/5.0 (Linux) mirall/3.8.2 (build 15392) (Nextcloud, ubuntu-6.8.0-51-generic ClientArchitecture: x86_64 OsArchitecture: x86_64)"],"Accept":["*/*"],"X-Request-Id":["a3ef5c25-4d82-42bb-bdbc-45379ba142c4"],"Cookie":[],"Accept-Encoding":["gzip, deflate"]},"tls":{"resumed":false,"version":772,"cipher_suite":4865,"proto":"","server_name":"cloud.example.com"}},"duration":0.001337109,"status":502,"err_id":"ivevqxvg3","err_trace":"reverseproxy.statusError (reverseproxy.go:1299)"}

I am attempting to solve this in many troubleshooting forums; I appreciate any help that can be provided here, and will post the solution here when it is found.

7

Partial success!

I installed a new image of Caddy with more modules, including Cloudflare DNS and DDNS support, from this repo. I then replicated the config described in this post.

Caddyfile:

{
        debug
 }

(cloudflare) {
        tls {
                dns cloudflare {env.CF_API_TOKEN}
        }
}

https://cloud.example.com:443 {
        import cloudflare
        reverse_proxy nextcloud-aio-apache:11000
}

Docker Compose file for Nextcloud-AIO:

services:
  nextcloud-aio-mastercontainer:
    image: nextcloud/all-in-one:latest
    init: true
    restart: always
    container_name: nextcloud-aio-mastercontainer
    volumes:
      - nextcloud_aio_mastercontainer:/mnt/docker-aio-config
      - /var/run/docker.sock:/var/run/docker.sock:ro
    ports:
      - 5050:8080
    environment:
      # - APACHE_ADDITIONAL_NETWORK=caddy
      - APACHE_PORT=11000
      - APACHE_IP_BINDING=127.0.0.1
      - NEXTCLOUD_DATADIR=<directory>
    networks:
      - caddy
      
volumes:
  nextcloud_aio_mastercontainer:
    name: nextcloud_aio_mastercontainer

networks:
  caddy:
    external: true

Docker Compose file for Caddy:

services:
  caddy:
    image: serfriz/caddy-cloudflare-ddns-crowdsec-geoip-security-dockerproxy:2.9.1
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
      - "443:443/udp"
    environment:
      - CADDY_INGRESS_NETWORKS=caddy,nextcloud-aio
      - CADDY_DOCKER_CADDYFILE_PATH=/etc/caddy/Caddyfile # I think this is a path inside the container?
    networks:
      - caddy
      - nextcloud-aio
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - ./Caddyfile:/etc/caddy/Caddyfile
      #- ./site:/srv
      - caddy_data:/data
      - caddy_config:/config

networks:
  caddy:
    external: true
  nextcloud-aio:
    external: true

volumes:
  caddy_data:
  caddy_config:

With all this entered, I was able to pass Nextcloud-AIO’s domain check, and Nextcloud-AIO reported that it successfully began all its component containers.

However, at that point, I ran into a new error: I couldn’t log in with the auto-generated admin username and password. But I’ll create a new issue for that.

8

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