We are also seeing the same issue with 3.7.0. The following error is showing in the nextcloud log after attempting to start collabra online:
Error richdocuments GuzzleHttp\Exception\ConnectException: cURL error 28: Operation timed out after 45001 milliseconds with 0 bytes received (see https://curl.haxx.se/libcurl/c/libcurl-errors.html)
for me it worked by rebooting my server
Same error here… after update to 18.0.5 from 18.0.3 i got the error. Collab server is reachable, but i can’t use in nextcould.
I have the same issue and also a reboot doesn’t help.
Did you use the redirection of all http to https during the Let’s Encript installation?
Colabora seems to be started, but it is not reachable in the Nextcloud Settings.
Also I got an Apache default Website if I try to open the FQDN of the colabora server:
I expected a Colabora Welcome Page or something like that. Is this normal, or did something go wrong with the colabora container itself?
Ok, nevermind …
I did a major mistake at
of the guide HowTo: Ubuntu + Docker + Nextcloud + Talk + Collabora
Instead of the public IP, I used 127.0.0.1 for NEXTCLOUD_IPADDRESS variable. After I fixed this, rebuilding the container and rebooting the server, everything is working fine now.
I installed Nextcloud and Collabora on an Ubuntu 18.04 server following the instructions at: HowTo: Ubuntu + Docker + Nextcloud + Talk + Collabora
When inserting the Collabora server address (office.domain.com) in the Nextcloud settings, I get following error: “Could not establish connection to the Collabora Online server”
Additionally I expected Collabora to show up at my “office.domain.com” website but the Apache welcome-page was there instead.
Installing and enabling the built-in CODE failed as well.
Any hints on how I can solve this issue.
I double checked the config files and repeated the installation already.
@anjo.weichbrodt Please start your own thread and show your Apache and Docker configs. If you’re seeing the Apache default site, then most likely something is wrong with the Apache config.
I opened the developer console and found an error that’s relevant:
Mixed Content: The page at 'https://cloud.domain.com/apps/files/?dir=/Documents&fileid=122' was loaded over HTTPS, but requested an insecure form action 'http://cloud.domain.com/custom_apps/richdocumentscode/proxy.php?req=/loleaflet/ed4f732/loleaflet.html?WOPISrc=https%3A%2F%2Fcloud.domain.com%2Findex.php%2Fapps%2Frichdocuments%2Fwopi%2Ffiles%2F126_ocbttb0r5cs1&title=Welcome%20to%20Nextcloud%20Hub.docx&lang=en&closebutton=1&revisionhistory=1'. This request has been blocked; the content must be served over HTTPS.
(I replaced my domain). Any ideas? I’m using the built-in CODE server and I’m updated to 19.0.2. This seems like a bug.
Did you managed to found any solution? I am also having similar problem.
Nope sorry, I went another route and thus stopped exploring in the direction of nextcloud/collabora for the moment.
That solution didn’t work for me. I tried the standard two-week maintenance routine on the docker parts and it didn’t fix things.
Did you mean you used
127.0.0.1 like this :
docker run -t -d -p 127.0.0.1:9980:9980 -e 'domain=sd\\.fqdn\\.tld' --restart always --cap-add MKNOD collabora/code
I’ve been doing that for many years now and it wasn’t a problem till recently. I’m in the 3.7.11 version of the Collabora Online app.
I carried out the installation exactly according to the following HowTo: Ubuntu + Docker + Nextcloud + Talk + Collabora - How to - Nextcloud community. This HowTo is using docker-compose and therefore a docker-compose.yml, which has some variables in it. I made the mistake that I have assigned the localhost IP to the variable NEXTCLOUD_IPADDRESS. Thus some port bindings was only set to the localhost ip and external access was not possible.
The NEXTCLOUD_IPADDRESS should be the LAN IP of your reverse proxy.
So if we are on a VPS directly connected to the internet, I guess this IP should be 127.0.0.1? I mean there is no LAN IP in such a machine.
Hmm… no, not necessarily. The reason for using the LAN IP is that the loopback address doesn’t work as you might expect inside a Docker container.
In a case like that, you might have to use the public IP. You’ll also need to make sure the VPS is allowed to connect to itself on that port (UFW or equivalent may block it), but not the rest of the internet.
I have to use the WAN IP in my case. I have ufw active but open ports for mail and http/https… it works now. Collabora wasn’t working at the beginning. Thanks a lot for your gift to the community! Great work!!
Karl, another problem has arised. Collabora works fine with Safari, however Chrome users see the following when trying to open a document
I read it could have to do with “Header always set” options, but I haven’t found any on my Apache configs. Maybe in the Nginx config inside the containers?
EDIT: Firefox gave away the problem. Certificate is untrusted. Something is not properly configured with the certificate.
Okay, so then you need to verify the certificate is correct and that you’re using the name on the certificate to connect to Collabora.