Collabora opens only files that are empty

ℹ️ Support 📄 Collabora
1

Just like the topic says. I’ve installed collabora using the official guide (with docker and nginx). I can access newly created files, but as soon as I edit them and save, I cant return to the documents. Docker log shows error below, while the webui times out with generic error. I will examine the issue in more detail, but maybe there is some detail I’m missing and someone will point me in right direction before I start pulling my hair.

wsd-00023-06 00:04:05.022314 [ prison_ws_0005 ] LOOLSession::handleInput: Exception while handling [status: type=text parts=1 current=0 width=12474 height=17406] in ToPrisoner-0005: Protocol error: The session has not been assigned a peer.

2

Meeehhh… Scratch that. After checking my proxy settings I realized my mistake. Everything works now.

3

Hello Muppeth.
What was the error in your nginx proxy conf ?
Regards.
Aal.

4

It was pointing to internal IP of the host it was running on instead of public IP. Though both collabora docker and my lxc nextcloud container run on the same host it is the browser that needs to resolve to collabora. I think it was sending uri with internal ip which couldnt be resolved by the browser.

5

Thank you Muppeth.
I have copied your solution.
Changing my nginx conf from localhost to my public IP solved most of my issues with collabora and nextcloud 10.
I have little knowledge about nginx and reverse proxy so I don’t know why pointing to localhost is recommended for nextxloud 9 but doesn’t work for nextcloud 10 on my server.
Regards. Aal.

6

Same issue here (same error message), but not always, just sometimes with the more complex files…
Are you sure you solved by using the public IP istead of localhost into nginx?
I tried that but with no luck. I’m asking because I noticed a little improved right after the nginx restart, but after some time the error come up again.
Trying 2-3 times to open the same document, it does open.
When it does not open, the collabora UI is shown but on the middle of the screen I have the icon loading forever… until the “Unexpected error…”

7

Hi,
Until I change the nginx conf, I could only open files with Edge and with a 30 sec delay.
Now i have about 2/3 opening rate succes on all browsers with just a 2 second delay… sometime more.
So it may have not “solved” litterally my issues but it made a big improvment.
Maybe some more tweaks are required to get a very good performance but I lack the knowledge to find it by now.
I’ll make more test later in the week to compare nginx/apache performances in the first place.
Regards
Aal

8

Solved adding these setting to the reverse proxy:

    proxy_buffer_size 128k;
    proxy_buffers 4 256k;
    proxy_busy_buffers_size 256k;

Now all the documents opens on the first time without the need to retry a second/third time.

1 Like
9

Hi Aventrax
I’m glad you have solved your issue.
No luck with mine. I tried thoses lines on my conf but it did’nt change the performances on my side.
Regards

10

So, you’re experiencing a 2/3 successfully open rate, right? what happens on the remaining1/3: do you have delay or an unsuccessful opening?
Are you using the docker image or do you build oo yourself?

11

I’m using the latest docker image, but I’m beginning to think it’s sort of a browser related issue :

Successfull rate has droped significantly this sunday on desktop chrome & firefox and still a 75% succes rate (+10 sec delay) on IE/Edge and 100% ( 2 sec delay ) on android Chrome.

On desktop chrome, still having 9/10 or more failed attempt per doc: the connexion icon appear until the proxy_read_timeout kick in and the message box “unexptected connexion error” appears.
No error in the docker image neither in the nginx proxy in debug.

In the browser debug, I see the web-socket handshake but the connexion is kept alive without transferring anything between the server and the client

12

Quite difficult to debug. I hate having a “successful rate” instead of a on/off (working/not-working) behavior… :slight_smile:
Moreover you’re experiencing different things with different browsers… so I’m not able to help.

IMHO there are still some issue with NC/OO, the app is marked as experimental, indeed I have 2 different behaviors on 2 different NC installations with (apparently) the same software/settings. I will be back if I will have news…

13

I stil struggle with the issue. I thought it has been solved but thats becasue my local /etc/hosts on my desktop was pointing to local proxy (scenario2). Below is my setup (scenario 1) which causes collabora to open documents once every few tries, and scenario2 which open documents at all times.

###Scenario1
I’m hosting nextcloud on Proxmox server with lxc containers and additionally docker image for collabora. I have one public IP which forwards requests for port 443 and 80 to proxy container with internal ip (10.0.0.1). This proxy container (running nginx) has two vhosts. 1st host - pointing to nextcloud container (internal ip 10.0.0.2) and 2nd vhost pointing to collabora docker image (public IP port 9800). This causes documents to not open every time.

###Scenario 2
The same setup as Scenario1 but instead of using 2nd vhost on proxy container (pointing to collabora docker), I setup local proxy on dev machine in the office, pointing to collabora docker image of the proxmox server. The only difference between this setups is that local proxy is pingable by my desktop, while proxy on the server is not (it has internal ip behind firewall).

I guess I need to setup additional headers for the proxy but so far I haven’t figure this one out. Maybe someone has an idea.

14

Hi there
I recently updated collabora docker image to latest version and the collabora nextcloud app
found out I still have the “connecting…” animated icon present for an infinite amount of time when opening any doc
but in the same time, switching from “viewing mode” to “editing mode” (lower right corner of the windows) instanlty load the file and allow editing.
well sometime it load nothing and I have to use the “switch page” icons to force loading.
So i think it’s some kind of improvment if i’m ignoring this breaks the Shared Editing feature of collabora

15

Hokay,

So after trying everything possible. I went back home since it was friday evening. Though I will have another battle monday anyway. However I decided to still have a look at the issue from home. Turns out I have 100% success rate when opening the documents, leaving me with probably an issue with local dns in the office.