Guide: Setup - Nextcloud AIO and Nginx Proxy Manager

[4lexRed]

Hey,
I just installed Nextcloud AIO behind a ngenix proxy manager on an exposed virtual server.
And I spent hours of searching why it would not start properly or why the nextcloud was not available under my domain name.

a simple alternative to the guide below

After fully writing this post and rethinking the issue I figured the following:
configure NPM to forward the dns-name nextcloud.yourhost.com to forward to port 11000 on 111.222.333.44 (your hosts public address) is the easiest and simplest solution to make NPM and Nextcloud AIO work together.
This works only for exposed hosts. [Behind a router this method fails. You need to follow the guide below]

Why this works:
As the Port 11000 is published on the hosts wan interface by the NC-AIO setup, the domain-checker-container (step 4) can be reached with this setting. Later, when the domain-checker-container is down and the nextcloud-aio-apache container is up, the later is reached via port 11000 (see screenshot for step 5 and 10 below fr an idea of running containers].

The longer, yet detailed guide

Here is my experience of the setup and a small guide to follow for the setup procedure with Nginx Proxy Manager.
It also gives a little bit of insight and understanding of what happens during the setup, as you can see the containers in portainer.

Note: pictures for the steps are at the end of this post

Download the compose file here.
It is well commented and does the whole setup of the npm, portainer, the Nextcloud AIO container and the network.
Please adjust the "path settings" for the data folders (I did not use docker volumes in the compose).

0. setup NPM and portainer (if not already happened)
   Details on NPM settings below

1. once you have the nextcloud AIO container running, access the NC-AIO setup website by opening https://your.docker_hosts.public_ip.address:8080

   Do not enter the the subdomain you want to use for your nextcloud (e.g. nextcloud.myhost.com).
   The website will not open if you try to access via the subdomain (guaranteed).

2. Save the password in the first screen (I forgot to do it and had to reset the instance)

3. Login to the AIO admin site (using the password from step 2).

4. enter the dns-address (e.g. nextcloud.myhost.com) to the AIO setup interface.
   Once you click submit, the check of the dns-address will fail. (This is were I was stuck for many hours)

5. open portainer and figure out which internal IP address the container "nextcloud-aio-domaincheck" has.
   (alternatively to portainer: use the command 'docker list' or alike)

6. configure NPM to forward the subdomain (e.g. nextcloud.myhost.com) to port 11000 to the internal ip-address from step 5.

7. go back to the AIO admin site and click submit (just as you did in step 4) .
   Now the address-check should work fine and the "domaincheck"-container will be stopped.

8. run the installation of the AIO containers with your preferred settings.

9. the installation procedure will eventually create a container called "nextcloud-aio-apache"

10. once the apache container is up, find its internal ip address (via portainer or docker list)

11. in NPM reconfigure your subdomain to forward to the hostname nextcloud-aio-apache
    Hint: its actually better to use the hostname instead of the ip, but you can also use the internal ip address.

    Be aware, the when tearing down and rebuilding the docker environment,
    the "nextcloud-aio-apache" might get a different internal ip address and you might need to adjust the setting in NPM.

12. now you should be able to access your nextcloud instance via the subdomain you have chosen.

13. (optional) reduce the amount of open ports to your containers by adjusting the compose file (see npm setup section)

NPM setup

My host & NPM setup is simple: one exposed (runs with a public ip address) virtual server running all docker containers [link to compose file is above].

The Nginx Proxy Manger [aka npm] is NOT set to network_mode = host, as recommended in the guide reverse-proxy.md - and I oppose to do so as I want all traffic to be routed by the NPM.

To reduce the amount of open ports on the host, once you finished the setup:

• set up the forwarding in NPM correctly forward the subdomains to the ports of each container

  • for npm.yourhost.com : forward to port 81 on "localhost"
  • for portainer.yourhost.com : forward to port 9443 on "portainer" (or use the containers ip - in the compose file it's 172.18.0.3)
  • for nextcloud-admin.yourhost.com : forward to port 8080 on "nextcloud" (or use the containers ip - in the compose file it's 172.18.0.4)
  • for nextcloud.yourhost.com : forward to port 11000 on "nextcloud-aio-apache" (there is no fixed IP for this container)

• check if your forwarding and the subdomains do work correctly

• then comment out the published ports in the compose file except for port 443 at the NPM container

• tear down the compose [via: docker compose down] and build it again [via: docker compose up].

After finishing the whole setup works with port 443 being the only open port.

In general it is recommended to use the containers names instead of ip-addresses, as NPM (or more precise: the Docker network) will translate the container names into ip-addresses.

"Error" in the reverse-proxy.md

In reference to the reverse proxy guide I want to explain one thing:
If the network_mode of the NPM is not set to "host", the Nginx Proxy Manager does not forward to the actual ip of the docker host when the forwarded host field is set to "localhost" (see picture for step 6).
Instead it forwards the requests to its own docker internal IP address (e.g. 172.18.0.2) on port 11000.
Hence the "nextcloud-aio-domaincheck" can never be reached with this setting and the admin (or user) is stuck with the error message "domain could not be checked".

Why I write this post

Walking through the configuration in the reverse-proxy.md I simply missed a clear explanation of the steps above during the setup process.
These should be mentioned under step 4 of the instructions for setting up the NPM reverse proxy.
And please at least mention at some point of the documentation that AIO creates an extra container for the domaincheck.

Question: publicly available port 11000

Is it possible to stop publishing the port 11000 - maybe via an environmental setting (aka keyword) in the compose?
This is a question interesting for server with direct access to the internet. If you are behind a firewall or at home, this question is of no matter.

At the state of writing the guide (March 2024), it was not easily possible to make the port 11000 not public.
In the posts below are a few attempts of how it can be achieved still to have the apache container not listening on the public.
I prefer a cronjob that deletes the iptables rule every now and then - but that is just me.

Pictures for the steps above

Step 1 - open AIO setup site & save your password (important!)

Step 3 - login

Step 4 - enter the dns name of your nextcloud instance

Step 5 - get the internal ip of the "nextcloud-aio-domaincheck"

Step 6 - edit the setting in the NPM to forward to ip-address from step 6

Step 8 - run the installation of the AIO containers

Step 10 - find the ip-address of the apache container

Step 11 - edit the setting in the NPM to forward to ip-address from step 10

[valecapaldi]

Hi there!!

first of all, thank you very much for you detailed explanation!.
Could you share your docker-compose and the config or .env files please?

[4lexRed]

Here is the compose file.
there is plenty of comments.
compose_-_nextcloud_all_in_one+npm.zip

I do not use any .env or config file apart from this. (Should I?)

[BstAA]

Question: publicly available port 11000

That's not a problem, as you will not open this port on your internet router. You have got more open host ports. I.e. 9000 for Portainer, maybe 445, 139 for Samba etc.

[4lexRed]

True - when using a DMZ (or alike) behind a router.

When using an exposed host (e.g. a rented vServer with public access) it is not true.
All my traffic to docker container has to pass the NPM.

I surely can block the port in the hosts firewall for external access, but why create a security risk in the first place, to patch it afterwards.
Should not be an issue for the NC-AIO team to use a keyword option to not (forcefully) publish the apache port on the host interface.

[BstAA]

Your completely right! After some (unseccessful) testing I found this not yet tested approach. One could bind the NC-Apache Container to host 127.0.0.1Accessing Host Services from Docker Containersdev.toAm 08.03.2024 um 11:16 schrieb 4lexRed ***@***.***>: True - when using a DMZ (or alike) behind a router. When using an exposed host (e.g. a rented vServer with public access) it is not true. All my traffic to docker container has to pass the NPM. I surely can block the port in the hosts firewall for external access, but why create a security risk in the first place, to patch it afterwards. Should not be an issue for the NC-AIO team to use a keyword option to not (forcefully) publish the apache port on the host interface. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>

[4lexRed]

And all this is possible with the cited "socat" relay.
Am happy to see your approach once it's finished. I think I know how you want to use it, but socat must be listening on the docker-internal LAN interface of the "nextcloud-aio-apache" container - whose IP address is "kind of dynamic".
Or you send all traffic through two socat interfaces.... by "abusing the host as a network-switch"
[ external http request <-> NPM-container <-- socat --> host <-- socat --> nextcloud-aio-apache - container ]

Keep in mind: you can not configure the "nextcloud-aio-apache" container in your compose file,
as the apache container is set up by script (or "by the mastercontainer").
You can only configure the mastercontainer in the compose.

So I think it might be impossible to get the
command: TCP-LISTEN:5432,fork,bind=host.docker.internal TCP-CONNECT:127.0.0.1:5432
line to be executed within the "nextcloud-aio-apache" container.

Anyhow: I am very curious how you will achieve a solution.

This is not to be seen in this view

Yes, in the portainer screenshot (the container overview) there is the column "published ports" for each entry.
It shows exactly this information. No need to have a look into the container view

Here you see that by using the proposed - APACHE_IP_BINDING=127.0.0.1 the port is only open on the lo interface

I still think a keyword / option in the compose file to enable / disable the published port would be the easiest and most understandable way.

[BstAA]

You can only configure the mastercontainer in the compose.

No: The compose of the mastercontainer is used to create the setup of the other containers, The only thing you have to do, is to follow Point 3 in the Reverse Proxy Documentation.

So instead of using - APACHE_IP_BINDING=0.0.0.0 just use - APACHE_IP_BINDING=127.0.0.1. Thus the apache container is listening to localhost only.

But to apply this, you have to delete all containers and start from scratch! 😥

By the way: It's not necessary to define everthing in one stack (docker-compose.ym) and at least for me ist much easier to maintain with one stack per application.

I'll show complete setup in the next comment

[4lexRed]

But to apply this, you have to delete all containers and start from scratch! 😥

Use compose files
docker compose down stops the containers and deletes them (but keeps any volumes attached to them)
docker compose up rebuilds the containers with the new settings
No need to fiddle with any ultra long 'docker start nextcloud-aio - env[....]' command, which you can not remember two weeks after setting up the container

It's not necessary to define everthing in one stack (docker-compose.ym)

The compose file (see the first post) was made specifically for this thread ;-)
In my live setup I also use multiple compose files.

[BstAA]

I use traefik instead of npm. Here my proposal for your npm setup:

1. Run your first setup using network_mode: host

It's not enough to recreate the nextcloud containers! You really have to delete all nextcloud-aio-* and the volume nextcloud_aio_mastercontainer i.e. startup from scratch. This way the nextcloud-aio-apache container is recreated with the new APACHE_IP_BINDING.

1. Adapt the compose file and npm settings

1. network_mode: host for service npm
2. - APACHE_IP_BINDING=127.0.0.1 for service nextcloud
3. remove - NC_TRUSTED_PROXIES="172.18.0.2"
4. configure NPM to forward the dns-name nextcloud.yourhost.com to forward to port 11000 on localhost

2. Run the complete setup

3. Shutdown NC-AIO via mastercontainer interface

2. Change your setup

adapt the compose file and npm settings

1. Add socat service to stack

ncaio-relay:
    image: alpine/socat:latest
    network_mode: host
    extra_hosts:
      - host.docker.internal:host-gateway             # define the local name host.docker.internal
                                                     # to point to the gateway of the standard bridge network
    command: TCP-LISTEN:11000,fork,bind=host.docker.internal  TCP-CONNECT:127.0.0.1:11000
                                                      # connecting to host.docker.interal:11000 will
                                                      # be forwarded to 127.0.0.1:11000

3. Modify service npm

• disable network_mode: host
• add

    extra_hosts:
      - host.docker.internal:host-gateway             # now it's possible to connect to docker.host.internal

• configure NPM to forward the dns-name nextcloud.yourhost.com to forward to docker.host.internal:11000

3. Recreate complete stack

docker compose up -d

4. Regarding open port 8080

Two options:

1. Limit access to localhost and use the socat solution
   for service nextcloud

    ports:
      - "127.0.0.1:8080:8080"

3. disable open AIO interface and open again if needed
   Just comment the ports lines
   In any case just recreate the modified container and not only restart

Hope that helps!

[4lexRed]

Thx for the reply and the effort you put into this.
I'll try socat and see if it works - even though this puzzles my mind a bit.
Did you actively try your solution?

Having

• socat running on the host network interface (network-mode = host)
• accepting connections on port 11000
• forwarding the connections on the loopback 127.0.0.1 interface on port 11000
  makes only sense if the container nextcloud-aio-apache is also running in host mode and can listen for packets on the hosts network interfaces.

But the config shows: the nextcloud-aio-apache is not running network-mode = host
and I can not change it's settings - only the mastercontainers settings.

But maybe I have a knot in my understanding of networking and the loopback interface - and will be surprised by the results of some testing.

Regarding open port 8080

• get a new subdomain - e.g. nc-admin.yourhost.com
• Disable the port 8080 for the service in the compose file
• configure npm to forward the subdomain to the hostname nextcloud-io-mastercontainer [or a fixed IP] on port 8080

done

Kind regards

[BstAA]

Did you actively try your solution?

YES! Otherwise I wouldn't put all the effort in my comment.

makes only sense if the container nextcloud-aio-apache is also running in host mode and can listen for packets on the hosts network interfaces.
No! If you set - APACHE_IP_BINDING=127.0.0.1 as mentioned in Point 3 in the Reverse Proxy Documentation before the first start, the nextcloud-aio-apache is generated with

ports:
      - "127.0.0.1:11000:11000"

and so it's listening on interface lo port 11000

But the config shows: the nextcloud-aio-apache is not running network-mode = host and I can not change it's settings - only the mastercontainers settings.

Yes! Recreating the master container will not recreate the apache container with the new settings. You have to really start from scratch as mentioned here 6. How to debug things?.
That's why I stated

It's not enough to recreate the nextcloud containers! You really have to delete all nextcloud-aio-* and the volume nextcloud_aio_mastercontainer i.e. startup from scratch. This way the nextcloud-aio-apache container is recreated with the new APACHE_IP_BINDING.

By the way: Your current setup exposes Port 11000 of the apache container to the public. If you would use network_mode host for NPM you would instead publish port 81 of NMP

Here is my complete setup using traefik

nc-diskussion.zip

The two networks have to be created by

docker network create proxy
docker network create nextcloud-aio

No need for fixed IP ranges or addresses. Of course "mydomain" has to be changed everywhere and the acme.json must have mode 600.
After that follow my comment above. The benefit if using traefik in a docker environment is, that the complete routing setup can done by labels in the docker-compose.yml file. See the included whoami example.

Regards
Klaus

[ebildebil]

One way could be to perhaps block port 11000 in the IPtables for all external traffic? Docker is quite good at punching holes in public facing VPS.

Another could be to assign a non public facing interface to the VPS and exposing 11000 on that one?

[4lexRed]

Thx so much!
I haven't seen the forest for all the trees!
Deleted the iptables ACCEPT line ... problem solved.

small help for others

search for the container
iptables -L DOCKER --line-numbers lists all the docker forwards.
Look for the line with the port 11000 forwarded to your nextloud-aio-apache container

Delete the port forwarding rule
iptables -D DOCKER X deletes the rule, where X is the number of the line (in the screenshot X equals 2).

Alternatively use this command - a one liner for "search for the right line and execute the deletion"

iptables -L DOCKER --line-numbers | grep "ACCEPT" | grep "dpt:11000" | awk '{print $1}' | xargs -I {} iptables -D DOCKER {}

Docker restart
with every restart of the docker service, docker re-installs it's rules to iptables.
So you need to have a cron job (or alike) running, that will make sure that the deletion of the rule is applied after every reboot / or every now and then.