No documents are shown after upgrading to loolwsd 4.0

I’ve just updated to the new 4.0 version of the loolwsd, and instead of being able to edit documents, only a white page with spinning wheel is shown.

I have not changed anything in the configuration, all was working fine with the 3.4 version.

I’m using the repository provided by Collabora and apache2 as the server running on Ubuntu 16.04.

I’ve been trying to find out why, but I was not able to do so. Can give me a hint as to what information could be relevant, or if anyone has experienced the same issue?

I’d appreciate any help.

Is collabora even running? Maybe it’s not starting after the update?

Yes, it is running. The reverse server is running too. Is there a way to try out Collabora itself without the Nextcloud integration, to open a local file using the web interface?

Maybe collabora does not see the files I am trying to open…

Well, have a look at the logfiles.

the most relevant part I was able to find was ERR Requesting address is denied: which should not have been, but even after fixing that the documents did not open.

 [ websrv_poll ] ERR  Socket #22 SSL BIO error: error:1407609C:SSL routines:SSL23_GET_CLIENT_HELLO:http request (0: Success)
dic 19 14:26:15 AO532h loolwsd[15042]: wsd-15042-15059 2018-12-19 13:26:15.590805 [ websrv_poll ] ERR  Error while handling poll for socket #22 in websrv_poll: error:1407609C:SSL routines:SSL23_GET_CLIENT_

This seemed to be somewhat relevant as well… but I wasn’t able to find out how to fix it.

And this is the most recent one:

dic 20 14:12:47 AO532h loolwsd[25317]: wsd-25317-26062 2018-12-20 13:12:47.402600 [ docbroker_007 ] WRN  Client session [0009] not found to forward message: o112 statusindicatorfinish:| wsd/DocumentBroker.cpp:1776
dic 20 14:12:47 AO532h loolwsd[25317]: wsd-25317-26062 2018-12-20 13:12:47.402688 [ docbroker_007 ] WRN  Client session [0009] not found to forward message: o113 signaturestatus: 0| wsd/DocumentBroker.cpp:1776
dic 20 14:12:47 AO532h loolwsd[25317]: wsd-25317-26062 2018-12-20 13:12:47.402777 [ docbroker_007 ] WRN  Client session [0009] not found to forward message: o114 invalidatecursor: { "viewId": "0", "rectangle": "1418, 1418, 0, 281" }| wsd/DocumentBroker.cpp:1776
dic 20 14:12:47 AO532h loolwsd[25317]: wsd-25317-26062 2018-12-20 13:12:47.402859 [ docbroker_007 ] WRN  Client session [0009] not found to forward message: o115 textselection: | wsd/DocumentBroker.cpp:1776
dic 20 14:12:47 AO532h loolwsd[25317]: wsd-25317-25321 2018-12-20 13:12:47.468678 [ prisoner_poll ] WRN  Waking up dead poll thread [docbroker_007], started: true, finished: true| ./net/Socket.hpp:622
dic 20 14:12:47 AO532h loolwsd[25317]: wsd-25317-25321 2018-12-20 13:12:47.470204 [ prisoner_poll ] WRN  Waking up dead poll thread [docbroker_007], started: true, finished: true| ./net/Socket.hpp:622
dic 20 14:12:47 AO532h loolwsd[25317]: wsd-25317-25321 2018-12-20 13:12:47.471828 [ prisoner_poll ] WRN  Waking up dead poll thread [docbroker_007], started: false, finished: true| ./net/Socket.hpp:622
dic 20 14:12:47 AO532h loolwsd[25317]: wsd-25317-25321 2018-12-20 13:12:47.473339 [ prisoner_poll ] WRN  Waking up dead poll thread [docbroker_007], started: false, finished: true| ./net/Socket.hpp:622
dic 20 14:12:50 AO532h loolwsd[25317]: wsd-25317-25334 2018-12-20 13:12:50.618409 [ websrv_poll ] WRN  WOPI host did not pass optional access_token_ttl| wsd/FileServer.cpp:610
dic 20 14:43:48 AO532h loolwsd[25317]: wsd-25317-25334 2018-12-20 13:43:48.743391 [ websrv_poll ] WRN  WOPI host did not pass optional access_token_ttl| wsd/FileServer.cpp:610
root@AO532h:/var/log/apache2# 

Ok. So you seem to have a SSL/TLS Problem. Maybe the loolwsd.xml got overwritten by the update?

I’ve checked it several time already, but I haven’t find what might be wrong.

Is there a way to access the collabora web editor without using nextcloud? Just to check if the editor is working?

Have a look at Socket Error when accessing Collabora. Seems to be the same problem.

thank you @himbeere ! I’ll check it when I get home, and I’ll post any results here…

Well, I have found the way to run Collabora office without Nextcloud here, I’ve switched off ssl for testing purposes, copied a file to /tmp/test.odt on the same server Collabora office is running on, and ran:

http://localhost:9980/loleaflet/dist/loleaflet.html?file_path=file:///tmp/test.odt&host=ws://localhost:9980

And I’m getting the Well, this is embarrassing, we cannot connect to your document. message.

Any ideas why this might be happening? (I’m am using a browser run locally via ssh -XC obviously, the interface of Collabora office does load up, but then I the message appears. I can see the test.odt file when listing file:///tmp/ in the browser.)

EDIT: I am able to open the file now using the link above (I needed to tweak the Storage settings, I am even able to use the https and wss to edit the file. Still cannot open files from Nextcloud.

When using the above-mentioned link, I do get this error message Error: forkit has more than a single thread after pre-init| kit/ForKit.cpp:540, but I am still able to open the document and edit it.

Hi,

I had similar error for a few months when I was using php 7.1. Updating to php 7.2 fixed it for me. More details in this thread here:

Hope this helps.

Well you’re way off from common practices. I suggest you install collabora the recommended way first. Use a vm, install collabora via ppa (https://www.collaboraoffice.com/code/linux-packages/) and configure nginx (https://www.collaboraoffice.com/code/nginx-reverse-proxy/) or apache (https://www.collaboraoffice.com/code/apache-reverse-proxy/). If you got that running we can talk. :slight_smile:

I have managed to get the whole thing working.

I was accessing nextcloud through a non-standard port (set on my router), after switching to a standard 443 port, everything works again.

I found out by accident when I was renewing my certificates. It is weird though, as everything used to work just fine on the non-standard port before.

I also have the problem with 4.0.0.2 using Docker using a custom port. Reverting to 3.4 fixed the issue. I found out that there seems to be some Content Security Policy problem that showed up in the browser console:

It is very strange because it works sometimes on other browsers.