Nextcloud Office won't open documents : !SOLVED!

Hello,
I’m struggling to repair Nextcloud Office functionality. I had it working some months ago, but after a time I discovered it would no longer open or edit files.

I host a Collabora Online server instance using docker on the same system as the nextcloud server, and after considerable effort re-building it now indicates that it’s reachable (green check) on the Administration Office page.

I can open https/.xxx/hosting/capabilities and find:

{“convert-to”:{“available”:true,“endpoint”:“/cool/convert-to”},“hasMobileSupport”:true,“hasProxyPrefix”:false,“hasTemplateSaveAs”:false,“hasTemplateSource”:true,“hasZoteroSupport”:true,“productName”:“Collabora Online Development Edition”,“productVersion”:“23.05.3.1”,“productVersionHash”:“a719c0f”,“serverId”:“03f9d6e6”}

And I can open https:///hosting/discovery and find:

<action default=“true” ext=“sxw” name=“view” urlsrc="https://… etc…

I’m unable to open the collabora admin web login page.

The Administrator Logging shows:

Error richdocuments GuzzleHttp\Exception\ServerException: Server error: GET https://<collabora instance>/hosting/capabilities resulted in a 500 Proxy Error response: 500 Proxy Error

Proxy E (truncated…)

The docker instance of collabora online was launched with this command:

docker run -t -d -p 127.0.0.1:9980:9980 -e 'domain=subdomain1\.domain\.xxx|subdomain2\.domain\.xxx' -e “extra_params=–o:ssl.enable=false --o:ssl.termination=true” -e ‘dictionaries=en’ -e ‘username=xxxx’ -e ‘password=xxxx’ --restart always --cap-add MKNOD collabora/code

This yields:
netstat -putan | grep docker
tcp 0 0 127.0.0.1:9980 0.0.0.0:* LISTEN 613528/docker-proxy

Both the Nextcloud and richdocuments builds are current.

I’m using this reverse proxy set up in apache2: (to be able post this, I’ve had to mangle all the links by removing “:/” . Don’t try to use this configuration as is!)

Encoded slashes need to be allowed

AllowEncodedSlashes NoDecode

keep the host

ProxyPreserveHost On

static html, js, images, etc. served from coolwsd

browser is the client part of Collabora Online

ProxyPass /browser http/127.0.0.1:9980/browser retry=0
ProxyPassReverse /browser http/127.0.0.1:9980/browser

WOPI discovery URL

ProxyPass /hosting/discovery http/127.0.0.1:9980/hosting/discovery retry=0
ProxyPassReverse /hosting/discovery http/127.0.0.1:9980/hosting/discovery

Capabilities

ProxyPass /hosting/capabilities http/127.0.0.1:9980/hosting/capabilities retry=0
ProxyPassReverse /hosting/capabilities http://127.0.0.1:9980/hosting/capabilities

Main websocket

ProxyPassMatch “/cool/(.*)/ws$” wss/127.0.0.1:9980/cool/$1/ws nocanon

Admin Console websocket

ProxyPass /cool/adminws wss/127.0.0.1:9980/cool/adminws

Download as, Fullscreen presentation and Image upload operations

ProxyPass /cool http/127.0.0.1:9980/cool
ProxyPassReverse /cool http/127.0.0.1:9980/cool

I’m a bit confounded by notes I’ve come across about coolwsd . I did not install or run that prior to my first working docker build with collobora online and nextcloud office. I’ve read posts saying that it can be helpful, or even needful, to run coolwsd alongside colobora-online server, but it doesn’t make sense to me. Out of frustration tho’ I’ve installed coolwsd and tried running it and tweaking its configurations to see if that would help. No luck with that. I haven’t found any clear or helpful notes on how exactly to use coolwsd, and it’s configuration file is a nightmare to parse.

The only remaining clue here I haven’t followed up on concerns the ‘500 PROXY ERROR’ , but I haven’t had luck finding help, or making sense of that.

Any pointers or suggestions would be deeply appreciated. I’m really stuck here!

Try this documentation and see what happens when you internet search for collabora CODE proxy 500 error. Search the forum and the collabora code github issues, along with nextcloud server and nextcloud office app github issues. Start with:

https://collabora-online-for-nextcloud.readthedocs.io/en/latest/install/

Thanks for the reply, and the additional links. They were very helpful.

I did eventually solve my problem.
I suspect I had a number of things misconfigured between not understanding the reverse-proxy, and being new to Docker. It was very puzzling to get a “Green Light” in the Office Admin configuration with the docker-based self-hosted CODE server, and yet have documents still failing to open. I wasted masses of time fiddling with the apache2 code for the proxy, and the docker container set up.

The short answer to the base problem was fairly simple:

The allow list for WOPI requests got misconfigured somewhere along the way. I had decided to update the host address to a subnet address for the docker-based collabora/code container, and when I did so I entered a subnet address without the subnet masq, ie, 127.15.0.0 instead of 127.15.0.0/16. I’d also modified what was a machine ip address for the host nextcloud server from 192.168.1.x to cover the lan subnet 192.168.1.0, again neglecting to put the /16 masq at the end.

These entries are apparently a bit sensitive requiring an exact format (as explained in the instructions on screen): Comma separated, with no extraneous characters or spaces. I have my suspicions they might be sequence sensitive, or otherwise cranky, because my first trials at amending them seemed to have no effect. But eventually I got some libreoffice docx and other files to open with the lan subnet first in line, and the docker subnet next.

The docker container build that worked was:

docker run -t -d -p 127.0.0.1:9980:9980 -e 'aliasgroup1=YourNextcloudSubdomain\\.Domain\\.Ext\' -e "extra_params=--o:ssl.enable=true " -e 'dictionaries=en' -e 'username=xxxxxx' -e 'password=xxxxxxxxxxxxxxxx' --restart always --cap-add MKNOD collabora/code

The apache2 reverse-proxy code, which I added via the Domains>Options>Apache Directives block in the ISPConfig3 site management system is as follows (found it on a web search here: Proxy settings — SDK https://sdk.collaboraonline.com/ documentation ).

########################################

Reverse proxy for Collabora Online

########################################

AllowEncodedSlashes NoDecode
 SSLProxyEngine On
 ProxyPreserveHost On


 # cert is issued for collaboraonline.example.com and we proxy to localhost
 SSLProxyVerify None
 SSLProxyCheckPeerCN Off
 SSLProxyCheckPeerName Off


 # static html, js, images, etc. served from coolwsd
 # browser is the client part of Collabora Online
 ProxyPass           /browser https://127.0.0.1:9980/browser retry=0
 ProxyPassReverse    /browser https://127.0.0.1:9980/browser


 # WOPI discovery URL
 ProxyPass           /hosting/discovery https://127.0.0.1:9980/hosting/discovery retry=0
 ProxyPassReverse    /hosting/discovery https://127.0.0.1:9980/hosting/discovery


 # Capabilities
 ProxyPass           /hosting/capabilities https://127.0.0.1:9980/hosting/capabilities retry=0
 ProxyPassReverse    /hosting/capabilities https://127.0.0.1:9980/hosting/capabilities

 # Main websocket
 ProxyPassMatch      "/cool/(.*)/ws$"      wss://127.0.0.1:9980/cool/$1/ws nocanon


 # Admin Console websocket
 ProxyPass           /cool/adminws wss://127.0.0.1:9980/cool/adminws


 # Download as, Fullscreen presentation and Image upload operations
 ProxyPass           /cool https://127.0.0.1:9980/cool
 ProxyPassReverse    /cool https://127.0.0.1:9980/cool
 # Compatibility with integrations that use the /lool/convert-to endpoint
 ProxyPass           /lool https://127.0.0.1:9980/cool
 ProxyPassReverse    /lool https://127.0.0.1:9980/cool

One remaining mystery that bugs me is being unable to open and explore the CODE Admin Console. When I go to https://subdomain.domain.ext/cool/adminws I get “HTTP Error 400”.

If anyone knows how to enable, find, and open that console, please chime in here!

Dear @skye,

I’m in trouble with kind of the same issue, here: Nextcloud and Collabora with Docker and WOPI requests allow list

Can you please supply your full working Wopi Access List?

Thanks a lot

Pascal

Just like this:

192.168.1.0/16,127.15.1.0/16

The lan subnet you can deduce from you router, and the docker container subnet can be deduced from:
docker inspect ‘container id’
Near the end of that output you will find the container ip address, and gateway address. The subnet address requires a ‘0’ in the last position. The masq /16 was suggested in another post exploring this problem, and worked for me.

Good luck!

@skye thanks a lot. Me and the users from the other tread will try it out.

This does not work for me :-/