I installed Nextcloud and the required apps (Nextcloude Office + Built-in CODE Server (ARM64)) on a new RasPi 4 with the latest 64bit Pi OS and PHP 8.1 (from external repository).
Since I also use some other web apps I donât want to move yet, the âpublicâ server (i.e. with port forwarding in the router) currently is an older RasPi forwarding the nextcloud subdomain to the new one via Apache (ProxyPass etc.), also handling SSL via LetsEncrypt while the âNextcloud Piâ is http only (with trusted_proxies and overwrite⌠settings in config.php).
In the Nextcloud Office settings, the server is shown as reachable, but if I try to add a document or âedit locallyâ, I see kind of a progress bar on top, and then nothing happens. In the browserâs console I see either âLaunched external handler for 'nc://open/@/Test.odt?token=âŚâ (Chrome) or a warning âPrevented navigation to ânc://open/@/Test.odt?token=âŚâ due to an unknown protocol.â (Firefox). This happens even if I select a Collabora test server (I tried the ones in Sweden and Ireland).
If I click on the setting option to use the build-in server again, I get âSaved with error: Collabora Online should use the same protocol as the server installation.â
So, maybe I need some additional forwarding or proxy settings? But then, why doesnât it work with test servers as well? And is there a way to avoid the warning in Firefox?
Also, (once it works), what should I put into the WOPI allow list? The external IPs (v4 and v6) arenât fixed, can I just put the server name or the internal IP there?
Thanks, thatâs at least a nice overview how it works with âusualâ CODE servers. But I canât do much of the troubleshooting steps with a test or the build-in server. For test servers, Iâm simply missing permissions, and the build-in one seems to wrap everything via https://myserver/apps/richdocumentscode_arm64/proxy.php. There seems to be an âinternalâ coolwsd running on port 9983, but I donât know if itâd be a good idea to mess about with itâŚ
Since it doesnât even work with test servers, I guess thereâs some issue with the Collabora server reaching my Nextcloud server. DNS and port should be fine (after all, I can reach my Nextcloud from everywhere), but as the data probably isnât the common http load, maybe I need some additional proxy settings?
Currently, itâs just
Or maybe Nextcloud ignores the âoverwriteâŚâ settings and passes the http address to the CODE server? Not sure how the RedirectPermanent would work out. The CODE server might not handle the 301 responseâŚ
I also wonder a bit about the nc://⌠- shouldnât this be some https request according to the article?
Little update:
Removed ProxyHTMLEnable and encoding workaround, which has been a copy&paste remainder from a case where I needed URLMaps.
Also tried ProxyPass(Reverse) for port 80 instead of redirecting, but as Nextcloud itself also redirects, Iâm not sure that has any effect.
If I use the build-in server, in the log I see âFetched capabilities endpoint from âŚâ working fine when trying to open a document, but no (logged) follow-up requests.
there are many hints for built-in CODE as well, especially in some linked threads. you are welcome to adopt the WIKI for built-in CODE variant this would be great help.
Thank you @WWE-Corey for coming back to my issue. I think I do have all variables set accurately as long as they are needed:
âtrusted_domainsâ =>
array (
0 => â#Server-IP#â,
1 => âserver.mydomain.deâ,
),
âtrusted_proxiesâ =>
array (
0 => â#Proxy-IP#â,
),
âoverwriteprotocolâ => âhttpsâ,
âoverwritehostâ => âserver.mydomain.deâ,
âoverwrite.cli.urlâ => âhttps://server.mydomain.deâ,
I intentionally left out overwritewebroot and overwritecondaddr as i want to access my NC only via external address on standard webroot.
Is there a more detailed documentation for CODE built-in server where I can find what config / headers is needed to accurately set urls?
To remind you: My setup is like:
Client(extern) â FritzBox â (SSL-in) HAProxy (SSL-Offload) â (http in) NC (w/CODE built in) and my domain points to my Fritz-Box with Port-Forwarding (443) to my HAProxy. On the HAProxy letsencrypt SSL Cert stuff is done and all further requests got to backend via http and not https.
regards, Felix
P.S.: I added to my proxy config something like:
X-Forwarded-Proto: https
but this does not help either. Where can i find what headers built-in CODE server relies on?
P.P.S: all valid urls https://server.mydomain.de/hosting/discovery, https://server.mydomain.de/hosting/capabilities, https://server.mydomain.de/cool and https://server.mydomain.de/cool/adminwsare handled by NC with 404.
P.P.P.S:
coolwsd.log shows:
wsd-81327-81327 2023-10-10 07:31:57.433934 +0100 [ coolwsd ] INF SSL support: SSL is disabled.| wsd/COOLWSD.cpp:2486
wsd-81327-81327 2023-10-10 07:31:57.433944 +0100 [ coolwsd ] INF SSL support: termination is disabled.| wsd/COOLWSD.cpp:2487
wsd-81327-81327 2023-10-10 07:31:58.299641 +0100 [ coolwsd ] INF Remote configuration is not specified in coolwsd.xml| wsd/COOLWSD.cpp:1220
and in the end of the log:
wsd-81327-81335 2023-10-10 07:32:00.608756 +0100 [ websrv_poll ] WRN convert-to: Requesting address is denied: #my external IP ADDR#| wsd/COOLWSD.cpp:4010
collabora-built-in lives at https://cloud.mydomain.tld/apps/richdocumentscode/proxy.php
@scheppi2610 you config looks more like stand-alone CODE⌠maybe this is the reason for issues?
I have no resource handy but I remember there was a thread here where adding reverse proxy X-FORWARDED* headers resolved issues for built-in CODE⌠turns out for some reason built-in CODE doesnât respect NC "overwrite*" settings - likely itâs linked to the above WIKI.
In general I would recommend to run dedicated CODE instance if your setup allows (CODE docker container is very easy). This recommendation is based on experience - often itâs easier to find docs and troubleshoot dedicated installation rather an integrated one when you rely on some magic and maybe undocumented hacks.