- I installed the Cloudron Collabora app.
- I set the Nextcloud domain at the Collabora domain
- In Nextcloud I installed the Collabora online connector app
- In Nextcloud I set the URL of the Collabora instance at:
- When clicking "Save" there I get "Could not establish connection to the Collabora Online server."
- I can successfully connect to a demo server.
@robi Yes, using FQDN
The Collabora app, (which is in the same Cloudron as Nextcloud App) is installed at:
Nextcloud is installed at
At "Cloudron Collabora Settings
https://collabora.mydomain.techI have entered into the field there:
I also tried
And then at:
https://nextcloud.mydomain.tech/settings/admin/richdocumentsI have entered into the field "Use your own server => URL (and Port) of Collabora Online-server"
I have also tried:
Thanks for the help.
@shai what you describe should work unless you have some typo somewhere. In fact the default collabora settings would already allow nextcloud to connect. I think there is some other network related issue somewhere. Can you open a webterminal into nextcloud and see if curl'ing to your collabora app works from there:
curl -v https://collabora.mydomain.tech
@shai that seems to be the root issue here. Can you check the certificate of that collabora instance and verify that you get a green lock in your browser? If so, are you using some special cert-chain setup on your PC, which the Cloudron may not know of to validate the whole chain? If you use the Cloudron default Let'sEncrypt, maybe try to renew all certs in the domains view.
@nebulon thanks for sticking with me on this one.
- green lock on all browsers on both
- I renewed all certs twice
- First time it essentially ran a check but didn't change anything because it saw the certs were fine.
- Second time I changed the cert type from LetsEncrypt wildcard to LetsEncrypt prod. This time it created new certs.
- I ran the curl to Collabora after each time that I renewed the certs. No change, exact same messages.
Some more data from my troubleshooting
I removed all the gazillion certs that were in
/etc/ssl/certsand also deleted all lines in
/etc/ssl/certs/ca-certificates.crtin advance of renewing my domain certs in the Cloudron domains admin page. Those actions had absolutely no effect on anything. Green lock still appeared on all my Cloudron sites and Nextcloud still couldn't contact Cloudron server.
find / -iname "*letsencrypt*"returned zero rows
Some wild ideas to just toss out there:
- Are there ever cert issues related to new TLDs like the
.techdomains that I am using?
- I've got two Nextcloud instances on the same Cloudron. (I've only been trying to connect 1 instance to Collabora.)
Again, I appreciate you sticking in there with me on this one. Any ideas on what I could try next?
- green lock on all browsers on both
@shai not sure what the issue could be but, you could send a mail to email@example.com with the exact domain names, if you don't want to disclose them, maybe we can get some clue from the certs then.
If you have other domains which are non
.techmaybe you could test installing collabora on those and check if this really is some tld issue, just to be able to rule out some concerns about that.
We got this sorted out on support@ . The issue was @Shai 's router does not actually support hairpinning. Because of this, he has added manual DNS server entries in the router to point to the internal Cloudron IP.
The fix is to to tell Cloudron also to remove to internal Cloudron IP for the apps. This was achieved by adding a local-zone as per https://docs.cloudron.io/networking/#internal-dns-server
@girish Similar problem here with a new Cloudron installation on a dedicated server with a public IPv4. The Nextcloud container cannot access the host's external IP (loopback issue?), thus it cannot reach the Collabora container by DNS name. I do not have access to update any routing settings external to my host server. Is there a similar internal DNS trick with Unbound I could try? Thanks!
Curl from within my Nextcloud container works with external hosts...
root@1971ddba-1e76-495e-b0f7-40ab4a544caf:/app/code# curl -v yahoo.com * Rebuilt URL to: yahoo.com/ * Trying 126.96.36.199... * TCP_NODELAY set * Connected to yahoo.com (188.8.131.52) port 80 (#0) > GET / HTTP/1.1 > Host: yahoo.com > User-Agent: curl/7.58.0 > Accept: */* > < HTTP/1.1 301 Moved Permanently < Date: Wed, 03 Feb 2021 21:33:41 GMT < Connection: keep-alive < Server: ATS < Cache-Control: no-store, no-cache < Content-Type: text/html < Content-Language: en < X-Frame-Options: SAMEORIGIN < Location: https://yahoo.com/ < Content-Length: 8 < * Connection #0 to host yahoo.com left intact
But not when trying to connect to my Collabora container:
root@1971ddba-1e76-495e-b0f7-40ab4a544caf:/app/code# curl -v collab.mydomain.com * Rebuilt URL to: collab.mydomain.com/ * Trying 131.xxx.xxx.xxx... * TCP_NODELAY set
@girish Thanks for the response! Restart of Unbound had no effect. Actually, the problem seems to be independent of DNS. I also cannot complete a curl request directly to the external IP of my host machine from inside the Nextcloud container. I can, however, complete a curl request from the host itself to the host's external IP. The problem only occurs when traffic originates from inside a container.
@staypath That's indeed strange that the container cannot ping the host IP. Is there anything unique about your setup we should know or is it the equivalent of a server with a public IP? Is there some special virtualization/networking going on?
@girish I ran some tcpdump sessions. When the container pings the public IPv4 of the host, the host responds to the ICMP packet, but it is responding to the private IP of the container (172.18.0.x). The packet doesn't seem to know how to get back to the container from the host.
@staypath Most apps don't. The only case I can think of on top of my head is if you had webooks when one app is calling the other. Say you setup GitLab notifications to rocket.chat but those are not configured out of the box. So, you will see the issue and they won't be failing transparently.
When the container pings the public IPv4 of the host, the host responds to the ICMP packet, but it is responding to the private IP of the container (172.18.0.x). The packet doesn't seem to know how to get back to the container from the host.
If you happen to have another server, can you test this with a normal ubuntu and docker installation ? i.e just create server, install docker. Then from a container try to ping public IP.
FWIW, this works out of the box in all the VPS servers.