but you use the nextcloud nginx proxy in front of collabora?
if you run nc and collabora on the same server - imho - you don’t need https between the nginx container and the collabora container. since the docker internal network is used.
and i think you put http here but configure the collabora container to use https.
so your nginx revers proxy is correct. you have to configure the collabora container to use http, dump the office domain stuff and put https://cloud.mydomain.com/ in the app config “URL of collabora online-server” field.
according to the nginx.conf it’s office.* (don’t know if you put * to hide your domain.)
did you try to put “everywhere” office.mydomain.com? also here in the collabora container section:
in my playbook i setup collabora/nextcloud to run behind a traefik reverse proxy to handle letsencrypt certs and ingress routing.
the domain variable in the collabora container environment is the nextcloud public fqdn.
please note that the domainname must be <your-dot-escaped-domain> i don’t know if this applys also to docker compose files. you may try.
the app setting is also the nextcloud fqdn.
so if you setup your own fqdn for collabora these two settings have to be consistent .
the nginx web server in front of nextcloud is configured to redirect the incoming traffic to the collabora container. but is listening only to port 80. the traefik container handles https. but the proxy_pass settings should be equal to yours.
I’m not sure I can totally contribute as you’ve gone the complete docker route. I only have collabora setup within docker (although heck I’d love to do more actually).
Where is your nginx reverse proxy? It looks by the way you are referencing things its in the docker network, however I didn’t see any nginx container mentioned in your configuration.yml file. Is nginx part of the nextcloud container?
To best test your system initially its probably easiest to eliminate the SSL stuff and go without certs. I know when I was setting up my stuff adding certs into a running setup caused a few errors which I was eventually able to solve. I’m glad however I took a stepwise approach in implementing these things.
In terms of your docker-compose collabora stuff, mine looks like this:
The server name should be the name of the collabora server.
The domain name is the nextcloud FQDN and not the double \. Those need to be in there.
My setup is an nginx reverse proxy that terminates for the nextcloud.example.com connection but then re-encrypts to the upstream collabora VM/Docker container. If you don’t need this re-encryption to the upstream collabora server then go with the option:
extra_params=–o:ssl.enable=false --o:ssl.termination=true and not - extra_params="–o:ssl.enable=true". The mounted volumes are only needed for re-encryption to the upstream collabora server using Let’s Encrypt certificates — so no need for these volumes if not re-encrypting to the backend.
If your nextcloud and collabora are part of the same docker network, I believe the nextcloud setting should be http://collabora:9980 (or if you have SSL enabled upstream) it would be https://collabora:9980 (this might give you a certificate error however since your certificate is going to resolve to office.mydomain.com — I’m not sure the workaround for this however I think office.mydomain.com would need to be added to the internal DNS server of the docker network (internal DNS server located at 127.0.0.11) or you would add your local DNS resolver for hostname lookup – google how to do that)
You should be able within a webbrower to connect to the collabora server correctly at https://office.mydomain.com (or http depending on setup) . You should see within browser just an OK returned. This cuts the reverse proxy out of the loop.
My setup is a little bit different than yours. I have my reverse proxy running natively on FreeBSD. Nextcloud also is installed on same machine as the the reverse proxy. Because I wanted originally to use Collabora, I needed a linux machine in the mix which I could either do a direct installation or go the docker route. I chose the docker method, so I have an Ubuntu Virtualized Installation with a docker collabora. Nextcloud has its own domain as well as Collabora similar to your setup.
It sounds like you’ve done things correct up to this point, but just make sure the router on your network can resolved the domain names to the internal LAN addresses. I usually have to create DNS Host Overrides at the router level to help me with this. An alternative would be to modify the /etc/hosts file on each VM/Machine/etc where you would add the domain name and associate it with an internal LAN address.
You need to make sure that each VM/Machine/Container/etc can see the other VM’s/Containers/etc. You can do this by doing the ping statement from each VM/Machine/Container to the other. You want to ping by domain name although you could check by IP address as well. It’s important to make sure you can ping by domain name since the domain name is attached to your SSL certficate. During the SSL handshake the domain names need to be resolved, so hence its important computers in your LAN be able to resolved each other by domain name. Docker has its own internal DNS resolver but I think if it doesn’t find the domain name within the its Docker LAN it uses the resources of the host machine.
You seem like you know what you’re doing with the Docker Images.
I’m not trying to dissuade you from what you’re trying to accomplish. I recently had the Docker Collabora setup and functioning within my Ubuntu VM/Docker setup. On a whim I wanted to compare Collabora to OnlyOffice and I installed OnlyOffice Docker last night on the same machine as Collabora. In terms of speed and overall features, OnlyOffice (OO) was a clear winner. I’m not trying to dissuade you from Collabora since setting up the OO Docker container was nearly the exact same steps as Collabora – so basically if you get one working you can get the other working as well. Honestly however I’d be hard pressed to recommend Collabora over OO based on features and just execution speed.