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.
i though you can do this with this environment. but this environment only controls the nginx/letsencrypt container. right?
then i think just try to put https://cloud.mydomain.com in the nextcloud app.
or https://office.mydomain.com. it should be the url of the nginx proxy in front of collabora.
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 thought domain was supposed to be my Nextcloud URL?
I actually did setup a CNAME for office.mydomain.com on Cloudflare, but Iām getting kind of confused. Am I supposed to enter the Nextcloud FQDN, or the Collabora FQDN in the Nextcloud settings.
Iāll change that and see if it does anything.
So should I be setting proxy_pass https://collabora_online: to a different port in my nginx config?
no. collabora_online is the name of the collabora container in my setup.
yours is collabora. i only wanted to show you that you have to use in both places the same address.
in your case the collabora fqdn. since you have an nginx server sending all request for office.* to https://collabora:9980.
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.
better try: https://office.mydomain.com/loleaflet/dist/admin/admin.html or https://office.mydomain.com/hosting/discovery
because only these urls are configured in the nginx config for collabora.
Setting that gives me the Failed to load Collabora Online - please try again later error when I try to run a test document. Using http does the same thing. No certificate errors.
Going to that gives me this message:
ā¦so I guess thatās good.
Out of curiosity, I checked the log for the Collabora container and it had this error:
SAXParseException: Tag mismatch in '/etc/loolwsd/loolwsd.xml', line 120 column 102
Can you describe your setup to me? Whats in docker containers and what is not.
Your domain names involved, etc. This thread is getting pretty long and I donāt have a great picture of your setup.
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.