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?
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.
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:
0 => ‘#Server-IP#’,
1 => ‘server.mydomain.de’,
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.
P.S.: I added to my proxy config something like:
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.
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
@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.