Collabora Sharing Document Connection

Hello everyone,

I’ve come across a bug in my setup and was wondering if anyone had any insight.

I am running Nextcloud in its own VM at 192.168.1.70
and running Collabora in its own VM at 192.168.1.83

I am using Nginx on the host to route sub-domains to the appropriate internal IP’s. ie. drive.domain.com -> Nextcloud.

I have Collabora forwarded in the same way using Nginx and connected to nextcloud with the plugin. Everything works as it should for all of your files in your account.

Where I am having an issue is when I share documents. If the document is in the root of the account when it is shared with another user, that user can open the document just fine using Collabora.

However, if that file is within any folder I get the error “
Well, this is embarrassing, we cannot connect to your document. Please try again.”

Here is my Nginx configuration:

server {
	listen 80;
	server_name office.domain.com;
	rewrite ^ https://$server_name$request_uri? permanent;
}

server {
    listen       443 ssl;
    server_name  office.domain.com;

    ssl_certificate /etc/pve/local/pve-ssl.pem;
    ssl_certificate_key /etc/pve/local/pve-ssl.key;

    # static files
    location ^~ /loleaflet {
        proxy_pass https://192.168.1.83:9980;
        proxy_set_header Host $http_host;
    }

    # WOPI discovery URL
    location ^~ /hosting/discovery {
        proxy_pass https://192.168.1.83:9980;
        proxy_set_header Host $http_host;
    }

    # websockets, download, presentation and image upload
    location ^~ /lool {
        proxy_pass https://192.168.1.83:9980;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $http_host;
    }
}

Quick update:

If I download the filed that has been shared, everything works properly. This seems to be an error in the linking of collabora to the document itself

When the document is shared, it shows up in the root of the shared user.

Could my Nginx not be getting the actual path to the shared file, rather it’s getting a different file location?

Does anyone have any insight? Does anyone have Collabora sharing working properly with Nginx? I really don’t want to have to switch to Apache for reverse-proxy on my host.

Does anyone have any ideas?

I do not have a solution but I`m in a worse situation - I cannot edit any documents, neither on root nor in any folder.

I have nginx serving both sites, the configuration you posted applies to my collabora configuration as well.
I will have to take a deeper look into the log files next as I cannot put my finger on any possible source for this behaviour yet.

Are there any nginx users who ran into the same problem and found a solution?

I still have not found a solution. In fact I’ve given up. I believe the NGINX tutorial needs updated on the Nextcloud site as the Apache tutorial and Host file had to be updated.

If the nginx manual didn’t get an update since the apache manual got, then it can’t work.
Probably you need set a similar kind of ProxyPassMatch "/lool/(.*)/ws$" wss://127.0.0.1:9980/lool/$1/ws
in the nginx config.

This has been my guess, however with little NGINX experience I do not know how to create the “right” host file to get it to work outside of basic web services.

perhaps @icewind who had setup up that documentation at icewind.nl may know a fix for that.

Seeing the same issue here. I installed according to https://icewind.nl/entry/collabora-online and the app loads fine in the browser, but I am seeing the following error when trying to open a blank document at the document root of Nextcloud’s file management on an admin user.

Well, this is embarrasing, we cannot connect to your document. Please try again.

Setup

  • CentOS 7
  • Nginx
  • php-fpm, PHP v7.0
  • MariaDB
  • Nextcloud 10.0.1
  • Docker installed Collabora 1.1.13
  • Port open in the software firewall and router
  • Connection made through HTTPS/Let’s Encrypt

Did you figure this out?

I haven’t figured this out yet but my immediate guess would be the nginx.conf; what though I couldn’t say.

Yeah still no progress on this. I am guessing you are correct about nginx.conf

These are the logs I am getting in Docker when trying to open a test document. I would guess that the issue is the office.domain.conf. I’m not sure what, but the errors make me think the issue is will LOOL.

I got the logs by running the following.

docker logs $CONTAINERID

[details=Summary]> kit-00065-1021 0:16:25.764869 [ lok_handler ] ERR Failed to load: file:///user/docs/65/Test.odt, error: loadComponentFromURL returned an empty reference| LOOLKit.cpp:991

kit-00065-1021 0:16:25.764915 [ lok_handler ] ERR Failed to get LoKitDocument instance.| ChildSession.cpp:316
kit-00065-1021 0:16:25.765004 [ lok_handler ] SIG Fatal signal received: SIGSEGV
Backtrace 65:
/usr/bin/loolforkit() [0x474d9c]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xf8d0) [0x7f120ab338d0]
/lib/x86_64-linux-gnu/libpthread.so.0(pthread_mutex_lock+0x4) [0x7f120ab2e274]
/usr/bin/loolforkit(_ZN12ChildSession21getPartPageRectanglesEPKci+0x4b) [0x44188b]
/usr/bin/loolforkit(_ZN12ChildSession12_handleInputEPKci+0xbe1) [0x44f2b1]
/usr/bin/loolforkit(_ZN11LOOLSession11handleInputEPKci+0x488) [0x45fc08]
/usr/bin/loolforkit(_ZN8Document14forwardToChildERKSsRKSt6vectorIcSaIcEE+0x433) [0x435f33]
/usr/bin/loolforkit(_ZN8Document3runEv+0x44b) [0x436d7b]
/usr/lib/libPocoFoundation.so.45(_ZN4Poco10ThreadImpl13runnableEntryEPv+0x99) [0x7f120bff7159]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x80a4) [0x7f120ab2c0a4]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7f120a86162d]
wsd-00027-0188 0:16:26.575570 [ child_ws_65 ] WRN Connection closed.| IoUtil.cpp:115
wsd-00027-0033 0:16:26.588763 [ client_ws_0010 ] WRN Connection closed.| IoUtil.cpp:115
wsd-00027-0033 0:16:26.588903 [ client_ws_0010 ] ERR Failed to send child [65] data [exit] due to: I/O error| DocumentBroker.hpp:136
wsd-00027-0033 0:16:26.588943 [ client_ws_0010 ] ERR Failed to send ‘exit’ command to child [65].| DocumentBroker.hpp:82
wsd-00027-0033 0:16:26.588980 [ client_ws_0010 ] ERR Failed to send child [65] data [exit] due to: I/O error| DocumentBroker.hpp:136
wsd-00027-0033 0:16:26.589014 [ client_ws_0010 ] ERR Failed to send ‘exit’ command to child [65].| DocumentBroker.hpp:82
wsd-00027-0033 0:15:54.062347 [ client_ws_0010 ] ERR Missing JSON property: 'OwnerId’
wsd-00027-0033 0:15:54.062396 [ client_ws_0010 ] ERR Missing JSON property: 'HidePrintOption’
wsd-00027-0033 0:15:54.062422 [ client_ws_0010 ] ERR Missing JSON property: 'HideSaveOption’
wsd-00027-0033 0:15:54.062488 [ client_ws_0010 ] ERR Missing JSON property: 'HideExportOption’
wsd-00027-0033 0:15:54.062527 [ client_ws_0010 ] ERR Missing JSON property: ‘EnableOwnerTermination’[/details]

Same situation here. I’ve tried it with both Apache and Nginx with the same result. I reinstalled Nextcloud today, made sure I had the latest Collabora Docker container and the latest Collabora Connector (1.1.15).

I don’t know enough about WOPI to even begin to guess how to debug this.

The Collabora container log has a bunch of these lines:

wsd-00026-0027 0:00:54.401717 [ client_ws_0003 ] ERR Error in client request handler: Connection refused| LOOLWSD.cpp:966
wsd-00026-0029 0:02:54.897025 [ client_ws_0004 ] ERR Error in client request handler: Connection refused| LOOLWSD.cpp:966

i had this issue too, got it fixed. If you post the result of:
docker info | grep -i driver

then I can tell you if my fix might work too

Hopefully you are onto something!
docker info |grep -i driver
``` WARNING: Usage of loopback devices is strongly discouraged for production use. Either use --storage-opt dm.thinpooldev or use --storage-opt dm.no_warn_on_loop_devices=true to suppress this warning.
WARNING: bridge-nf-call-iptables is disabled
WARNING: bridge-nf-call-ip6tables is disabled
Storage Driver: devicemapper
Execution Driver: native-0.2
Logging Driver: journald

hmm in your case it doesn’t look well bacause my fix was switching to the devicemapper.
I used aufs and overlay. I got the same issue with them,

I applied this:

cp /lib/systemd/system/docker.service /etc/systemd/system/
    editor /etc/systemd/system/docker.service

search for the following line
ExecStart=/usr/bin/dockerd -H fd://
add the storagedriver option
ExecStart=/usr/bin/dockerd --storage-driver=devicemapper -H fd://
restart systemd, docker and your container
systemctl daemon-reload
    systemctl restart docker.service
    docker run -t -d -p 127.0.0.1:9980:9980 -e 'domain=YOUR.CLOUD.COM' --restart always --cap-add MKNOD collabora/code
This last command also starts a download of the collabora container. Changing the storage driver also removes the according aufs folder in the docker /lib folder and all contents.

Perhaps it helps in you case too if you applied the driver via the json file and not via the execution-parameter directly.

Unfortunately, my docker.service file is quite different. I’m not sure what the ramifications would be of changing that as I do have a Discourse container running as well.

[details=docker.service]```
[Unit]
Description=Docker Application Container Engine
Documentation=http://docs.docker.com
After=network.target rhel-push-plugin.socket
Wants=docker-storage-setup.service

[Service]
Type=notify
NotifyAccess=all
EnvironmentFile=-/etc/sysconfig/docker
EnvironmentFile=-/etc/sysconfig/docker-storage
EnvironmentFile=-/etc/sysconfig/docker-network
Environment=GOTRACEBACK=crash
ExecStart=/usr/bin/docker-current daemon
–exec-opt native.cgroupdriver=systemd
$OPTIONS
$DOCKER_STORAGE_OPTIONS
$DOCKER_NETWORK_OPTIONS
$ADD_REGISTRY
$BLOCK_REGISTRY
$INSECURE_REGISTRY
LimitNOFILE=1048576
LimitNPROC=1048576
LimitCORE=infinity
TimeoutStartSec=0
MountFlags=slave
Restart=on-abnormal

[Install]
WantedBy=multi-user.target

Not sure what happened; it might be something with the connector app, but the office application is working for me now. I didn’t change anything other than performing a reinstall from Nextcloud of the connector app.