Have a docker environment on Ubuntu, new NextCloud AIO installation with the nextcloud_aio_mastercontainer on a dedicated macvlan with internet access and NAT provided by a Fortigate firewall.
A DNS entry is configured on the internet for hostname.domainname.com and can be resolved from within the container(s) without issue. NAT is set up so that inbound NAT and outbound NAT return the same destination/source IP address for all requests.
When I’m accessing the NextCloud interface post-install I am receiving an error message “The domain is not reachable on Port 443 from within this container. Have you opened port 443/tcp in your router/firewall? If yes is the problem most likely that the router or firewall forbids local access to your domain. You can work around that by setting up a local DNS-server.”
NextCloud AIO installs (2) containers by default - nextcloud_aio_mastercontainer and nextcloud-aio-domaincheck. During the installation the mastercontainer was placed on the macvlan, the domain check container placed on a nextcloud created bridge network.
It is unclear from which container this error is coming from. Do both containers need to resolve to the same DNS entry/IP address on the internet? What ports need to be opened to the mastercontainer vs the domaincheck container?
I’ve tested multiple configurations including two separate external IPs and inbound open ports to the two containers but cannot get past this error. I need to create a certificate for this system, looking to do that via the nextcloud letsencrypt process so don’t want to bypass domain checking.
Networking is fine, there is no firewall enabled at the linux host level, the internal routing works just fine, I can access the mastercontainer from the internet :8443 without issue, etc. but cannot get past this error message.
Any assistance appreciated:
Ubuntu Linux
Docker
NextCloud AIO
No reverse proxy, Fortigate NAT
A record configured
(2) containers running without issue
Mastercontainer running on a dedicated Macvlan
Domain check running on the NextCloud created bridge
I’ve also tried split DNS internally but the domainchecker knows that it’s an internal IP and will not proceed.
I’ve also put the domainchecker container on the same macvlan as the mastercontainer, DNS checking is still failing.
The last potential test is to run the AIO script without placing the mastercontainer on the macvlan but I don’t want the running containers on the same network as the docker host.
Once I removed the installation with the macvlan setup and went with the default script the domain checking function worked. Same VIP, just a different IP on the host bridge network for the mastercontainer.
I’ve replaced the macvlan with an ipvlan and the installation moved forward - with the mastercontainer on the ipvlan and all others on the nextcloud-aio bridge network.
The installation was ok, until errors started appearing from apache that let’s encrypt could not create a certificate (error below) and notify push not starting correctly.
Any recommendations on how to run AIO off of the bridge would be appreciated, next step is to reinstall (again) with no other network than the default nextcloud created bridge network and see how that goes…
2024-12-24T01:22:59.981849693Z Connection to nextcloud-aio-nextcloud (172.x.x.x) 9001 port [tcp/*] succeeded!
2024-12-24T01:22:59.983084967Z The notify_push binary was not found.
2024-12-24T01:22:59.983109294Z Most likely is DNS resolution not working correctly.
2024-12-24T01:22:59.983114039Z You can try to fix this by configuring a DNS server globally in dockers daemon.json.
2024-12-24T01:22:59.983117364Z See https//dockerlabs.collabnix.com/intermediate/networking/Configuring_DNS.html
2024-12-24T01:22:59.983125700Z Afterwards a restart of docker should automatically resolve this.
2024-12-24T01:22:59.983128883Z Additionally, make sure to disable VPN software that might be running on your server
2024-12-24T01:22:59.983138980Z Also check your firewall if it blocks connections to github
I’m not exactly understand what are trying to achieve and why you are trying to run AiO in a macvlan or ipvlan network. it is important to understand AiO is built with some assumptions in mind. It is supposed to create a self-configuring solution where the mastercontainer creates and manages many other containers. This might result in something different you expect. I would review the working non-customized solution and adjust to your needs if required.
there are mentions of different networking options which might be relevant for you.
AiO is also not designed to control every possible configuration - change to the Docker micro services aka community image if you want more control over the installation (at the price of more work)
For every server we build there are a few networks - client, management, backup, etc. - that are part of that build. For AIO we were working on putting the containers on a specific network, we’ve just had to revisit the design with the initial default network as the container network, adding another interface for management, etc.
Working with the AIO script it appears the assumption is that everything is on a single bridged network, we arrived at that conclusion through a lot of testing
The only thing we ended up modifying in the AIO script was the default location of data storage, and that did not work out well initially - IMHO that is because the syntax in the script needs to point to the actual mount point of your intended data directory (in Linux) - for example:
-env NEXTCLOUD_DATADIR=“[/mnt/pathtoyourmountpoint]” \ and not ncdata. To set that up initially we added an xTB disk, formatted it, created the /mnt/[subfolder] and then mounted it.
It would be nice if NextCloud built a “data move” facility into the system but since we had already installed to /mnt/ncdata on the boot partition we shut down all of the containers, removed the mastercontainer, linked /mnt/ncdata to /mnt/[subfolder] and re-ran the installer with the proper environment command to recreate the mastercontainer and storage link and rsync’d the data from /mnt/ncdata to /mnt/[subfolder] and brought the containers up - no issues. The GUI now shows /mnt/ncdata on a multi TB partition.
To point the linux default nextcloud /mnt/ncdata to another target:
AiO is not intended to be fully customizable… it’s rather follows simple “fast food” approach. now time many many customization options where added but it still prefers ease of use over administration complexity.
I’m not expecting full customization from AIO, but nothing in the documentation prohibits changing what networks the installation uses - but that change only applies to the mastercontainer by default. Again, none of this is documented and yes, contrary to the notion your very large image proclaims, I’ve read the documentation.
The reason we’re using AIO, not that you asked, is because NextCloud recommended we use it as it’s supportable and part of the NextCloud standard offering. We had a few other installations in POC and AIO was the last and will be the one we’re moving forward with. Overall we’re happy with the result.
What should be simple to customize is the location of the file storage which many don’t want to reside on the root of the server on which it is hosted.
Following the documentation, and spending hours on the phone with NextCloud, I’ve found that although my mount point is correctly configured and the ENV variable used in the setup script is correct there are still persistent references to /mnt/ncdata in the installation that are not resolved by using the script.
IMHO selection of the storage location should be something that you can do during initial installation, as well as in the future when moving to different storage post-installation.
This should be accomplished at the system level, with a provided tool, after installation to ensure the database, as well as configuration files, are appropriately configured and not risk an unstable installation with questionable directory permissions/functionality.
Moving the data directory is a frequent question, not out of the realm of the possibility of requesting a feature that enables an admin to accomplish this (or perhaps even a replica) via the NextCloud UI.
For the backups I did find in the documentation what directory permissions are required/expected/recommended for a Linux /mnt/backup backup destination - the same for any other NextCloud data directory? Any citations/recommendations please feel free to post!
