Issue installing Collabora following official guide

Hey guys,
i compiled code by myself on debain 8 and now i want to connect my nextcloud to it.
But there is a issue while connection:

WOPI host is not on the same host as the WOPI client: "141.65..". Connection is not allowed.
No acceptable WOPI hosts found matching the target host [*.ufz.de] in config.

At the moment there is only a selfsigned certificate… maybe this is the prob?


ok… i fixed this. You have to edit the loolwsd.xml.in and add your nextcloud-host.
But now there is the next prob…

WOPI::CheckFileInfo returned: {“message”:“App is not enabled”}
[ loolkit ] Connection closed.
[ client_ws_0001 ] ClientRequestHandler::handleRequest: BadRequestException: Invalid URI or access denied.

Well tests domage that it does not work

Some typical problems I’ve seen are now covered on https://nextcloud.com/collabora online, troubleshooting section on the bottom of the page.

Any suggestions of things to add would be super welcome.

@Pisoko your problem looks like one of those addressed there: you might have started the docker container with the wrong host URL. At least, that’s what was the cause of this same error message for me.
@julio1501 be sure to check the video, I also talk about the firewall. It might be a cause of trouble, I discovered that no amount of tuning could fix the problem after I had started the firewall - you need to start docker AFTER you started the firewall… It does some iptables magic. Haven’t figured out how to persist this all properly, tbh.

Hello, I have same problem as @julio1501 in Debian 8 but so I have no firewalls. Collabora Office conteneur listen on contener ip and 9980 port and all traffic is proxyfied by nginx proxy on port 443

Seems to have same issues like @julio1501 and @guidtz

[ client_ws_0003 ] WOPI::CheckFileInfo returned: {“message”:“App is not enabled”}

[ client_ws_0003 ] ClientRequestHandler::handleRequest: BadRequestException: Invalid URI or access denied.

are there news what the problem could be?
thx guys!

hello @guidtz after compiling the packages on my debian machine instead the docker installation i got it working.
I suspect the problem was due to a conflict between docker network and our entreprise Firewall respectively reverse proxy.

Thanks

Hi,

I am using nextcloud 9.0.53 with docker 1.11.2 on debian 8.5, and it still doesn’t work. In the logs I have this errors:
kit-00091-04 00:01:44.229483 [ kit_queue_0003 ] Failed to load: file:///user/docs/91/Django_astuces.odt, error: >loadComponentFromURL returned an empty reference
kit-00091-04 00:01:44.229818 [ kit_queue_0003 ] Failed to get LoKitDocument instance.
[…]
wsd-00022-00 00:01:45.277989 [ prison_ws ] SocketProcessor: exception: Connection reset by peer

Do you have an idea of where is the problem? I have tryed disabling the firewall, then restart docker with no firewall, without success.

@julio1501, can you explain how to compile it and run it without docker? May be it could solve my problem :slight_smile:

Thanks

I have a quick question in the virtual host section of the guide it says to use lets encrypt. I want to take the easy route and do that but I am missing a step somewhere. Can someone take me step by step on how to get lets encrypt to do its thing?

Hi everybody,

following the installation guide I can’t enable the “collabora online connector” (1.1.3) in my nextcloud 9.0.53 installation >> error message: “App can’t be installed because of not allowed code in the App”.

What to do next?!? Thanks!

Will be happy to know how do you compile this packages, because I’m in the same boat. Thank you!

hello @Access_Forbidden, following this tutorials:

libreoffice core: https://www.libreoffice.org/about-us/source-code/
loolwsd: https://github.com/LibreOffice/online/tree/master/loolwsd
loleaflet: https://github.com/LibreOffice/online/tree/master/loleaflet

hello, good for you’re compiling but I think we can do it with the docker image.
I’ll continue to search why It doesn’t work

hello @guidtz, there are some things I’m wondering about (bold printed). Here are some log details from my docker container with collabora:
[ client_ws_0008 ] WOPI::CheckFileInfo header for URI [https://xxxxxxxxxx/index.php/apps/richdocuments/wopi/files/xxxxxxxxxx?access_token=xxxxxxxxxx]:
Server: nginx / Date: Mon, 01 Aug 2016 07:55:49 GMT / Content-Type: application/json; charset=utf-8 / Content-Length: 32 / Connection: close / X-Powered-By: PHP/7.0.8 / Set-Cookie: nc_sameSiteCookiestrict=true; path=/; httponly;secure; expires=Fri, 31-Dec-2100 23:59:59 GMT; SameSite=strict / Set-Cookie: nc_sameSiteCookielax=true; path=/; httponly;secure; expires=Fri, 31-Dec-2100 23:59:59 GMT; SameSite=lax / Set-Cookie: oc_sessionPassphrase=xxxxxxxxxx; path=/; secure; HttpOnly / Set-Cookie: xxxxxxxxxx; path=/; HttpOnly / Expires: Thu, 19 Nov 1981 08:52:00 GMT / Pragma: no-cache / Cache-Control: no-cache, must-revalidate / Content-Security-Policy: default-src ‘none’;script-src ‘self’ ‘unsafe-eval’;style-src ‘self’ ‘unsafe-inline’;img-src ‘self’ data: blob:;font-src ‘self’;connect-src ‘self’;media-src ‘self’ /
[ client_ws_0008 ] WOPI::CheckFileInfo returned: {“message":"App is not enabled”}

[ client_ws_0008 ] ClientRequestHandler::handleRequest: BadRequestException: Invalid URI or access denied.

In the Nextcloud Log I found the following:

Now I copy & paste the URI to my local browser and give it a try… I was wondering because it seems to work as expected: I got the file information back as associated array.
Next I logged out from Nextcloud on my browser and gave the URI the next try: Now I got the same message back like in the collabora log: Access denied. App is not enabled.

Did you already found anything?

Not sure if the nginx proxy could be the “evil part”…

1 Like

Same issue with my apache here :wink:

Hey,

Nice guide @jospoortvliet everything seems to work exept the editing itself. It gives me some errors about that the private user key is not loaded, logout and in again… just like enableing encryption in Nextcloud.
Altought that just doesn’t do it… Anyone any idea? (image down below)

–restart always doesn’t seem to autostart at boot, had to add it to /etc/rc.local
edit: i found this, we should look into this on failure setting or so.

Find the Docker’s Restart Policies

I’m working on a script to do all this stuff automated, you can help out here: https://gist.github.com/ezraholm50/01e3b1a3b33f329b081e1ed6c632d3ea

When its stable we could implement it somehwere in the repo’s, of which the VM cloud be one…

1 Like

Sorry I can’t answer many questions, this is very new for me too :wink:

Anyone who finds a solution for their problem, PLEASE edit your comment or provide a new one with the solution so others can use it!!!

@Pisoko: which version of “Collabora Online” app is installed on your NC? I fixed the issue on my NC installation, but I’m not 100% sure what has been the issue…

I’m seeing a slightly different issue to most people here by the looks of things. My Collabora install which I must admit is a minor deviation from the official line is running into the following curl errors :

Collabora Online unknown error: cURL error 56: SSL read: error:00000000:lib(0):func(0):reason(0), errno 104
Please contact the “https://office.mydomain.com” administrator.

The deviation I speak of is an Nginx Reverse Proxy that I use to make all my different webservices easier to manage in my home. I added a block to my nginx reverse proxy as described in the official documentation for office.mydomain.com changing the 127.0.0.1 references to the IP of the server hosting the Collabora Docker Container. This is also a dedicated standalone server seperate from my NextCloud instance. I also have a seperate dedicated DNS server with all of my A and CNAME records resolving to my Reverse Proxy.

A few things of note that I’ve had a look at, I don’t seem to have any entries in the Nextcloud logs, also the docker logs don’t seem to show anything at all.

If I issue a curl -v https://office.mydomain.com from any of my other linux servers I get the normal response up until the part of the response where I should get the HTML from the nginx welcome screen of the Docker container, instead I get the error listed above. If I issue the same curl -v https://office.mydomain.com from the server hosting the docker container I get the correct response. I believed this initially to be a firewall issue so I’ve disabled the UFW on this server (ubuntu 16.04) but no joy. I get the same errors.

Now I understand that this is not the documented way of configuring Collabora with nextcloud as per the official post but it should still work fine as I have configured a lot of reverse proxy blocks for many different servers.

Could anyone offer me any advise on what could be causing this error.

Regards,
Laoistom

@amilomx I run with 1.1.3 of the richdocuments app.

I am just wondering, since I have a Apache proxy in front of NC and Colabora, would I need to setup websocket proxy for the NC config (on the Apache proxy) so Colabora can use it to connect to NC?

In the docker output I can see a reference to websock back to NC:

wsd-00021-02 00:36:32.028148 [ client_req_hdl ] Request from 192.168.7.241:40259: GET /lool/ws/https://cloud.<mydomain.com>/apps/richdocuments/wopi/files/288560?access_token=NPMKOWnAO5lG5a97vJC8sKPcd1qqDV7Q HTTP/1.1 / Host: office.<mydomain.com> / Pragma: no-cache / Cache-Control: no-cache / Origin: https://office.<mydomain.com> / Sec-WebSocket-Version: 13 / DNT: 1 / User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.82 Safari/537.36 / Accept-Encoding: gzip, deflate, sdch, br / Accept-Language: en-GB,en-US;q=0.8,en;q=0.6,nl;q=0.4 / Sec-WebSocket-Key: SSrqq5P/ZpDkYinxO6+RxA== / Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits / X-Forwarded-For: 192.168.7.1 / X-Forwarded-Host: office.<mydomain.com> / X-Forwarded-Server: office.<mydomain.com> / Upgrade: WebSocket / Connection: Upgrade