I’ve got two servers at home. On one (serv.a), I’ve got Nextcloud installed and working. On the other one, (serv.b), I’ve got a Collabora server. The servers have separate domain names.
I’ve installed Nextcloud office and filled the mains fields. When opening a file, everything’s fine: it launches the Collabora interface and I can edit my document.
But, I would like to fill the field “Allow list for WOPI requests”. I’ve tried many things : public IP of serv.b, local IP of serv.b, in IPv4 and in IPv6, IPv6 prefix, IPv4 local subnet… nothing works and when trying to open a file it ends up by saying “Please try again later”.
I have also encountered this, and I even got wireshark involved: my proxy sends requests from 127.0.0.1 to 127.0.0.1 with X-Forwarded-For: 172.16.0.2, and putting both of those ip addresses, plus my public, link local, and local-network IP addresses in the WOPI field failed, so I filed a bug: [BUG]: Allow list for WOPI requests isn't honored · Issue #2685 · nextcloud/richdocuments · GitHub
Looks like we can’t enable the allow list until this bug is fixed
I had the same problem with the WOPI requests.
An empty field always works. If my public IP is in this field, then no document is opened.
I have Collabora CODE running in Docker and Nextcloud 25.0.2 natively on the same device.
The Collabora CODE server is accessible with a subdomain and also works with an externally hosted Nextcloud, just not with my Nextcloud.
In my case, I have now found the cause.
In my case, it was due to an incorrect setting in the Pi-hole.
I entered my Nextcloud subdomain under Local DNS Records. That was wrong!
After I removed this entry, opening the documents worked again without an error message.
I have now entered the IP address ranges of my provider in the field.
These ranges can be found here, for example. Telekom Vodafone
Finally, it seems we encountered three different problems. @Crashandy found a solution by (him|her)self while @byteit101 and I were helped on Github by @juliushaertl For the last two of us, fixes should soon happen so nobody stumbles upon this after next release. Before that, two things to note:
If you enter a list of IP or ranges, separate them by a comma only (no space at all) such as in 127.0.0.1,192.168.0.1 (@byteit101 problem)
If you enter an IPv6, append a prefix length: /128 if you enter a full IPv6 (my problem)
What exactly did you do in order to identify the IP address in wireshark? My collabora is reverse proxied by NGINX, while nextcloud is directly running on NGINX. Which requests did you intercept?
UPDATE: I now added the ip address of the docker container shown by docker container inspect [name of collabora container], and now it works! Yay!
Just in case somebody still has this problem: My nextcloud runs on the host, behind nginx, collabora is running in docker as well behind nginx. I sheepishly allowed 127.0.0.1 and my public ip. But I forgot that the container has its own private address. So I added the private ip range (since who knows when the containers IP changes…) I setup for docker (there is only the collabora container on the system anyways) and it worksl
I tried to allow all IPv4 adresses 0.0.0.0/0 but that doesn’t work for me (Hetzner Storage Share, Collabora running on an different VM with nginx reverse proxy).
I don’t understand. If I select Built-in Code, why simply it could lock those restrictions to the localhost? Does it mean I was exposed to the security hole all that time?
Similar problem, can’t for the life of me sort it out.
Nextcloud 29 (though behavior is the same in 28.0.5)
Ubuntu 22.04LTS
NOT in containers or VMs; this is a raw install to the hardware.
local network in CIDR notation, gateway IP for the router, External IP, none work, not even the individual client IP works. I have to be missing something PAINFULLY obvious.
I will state that the server has its own little oddity that I’ve been battling for a few months - Cannot access the server by domain name from in-network
WOPI requests are from Collabora server providing client features for editing files. As I understand your post, you add the users client IP range not Collabora server IP.
Docker with Collabora server on 172.16.0.2, use 172.16.0.0/24 (subnet, IP will change in docker).
Collabora server on the localhost I assume the server loopback, 127.0.0.1,::1 (I use Docker).
If you look at access log to your nextcloud server this should show the IP to collabora server.
I struggled as well with this WOPI thing : I’m on a raspberrypi (no docker), using the Built-In CODE server. Since the server and Nextcloud are on the same machine, I thought I should use 127.0.0.1, but… Nope.
I had to use the gateway IP of my server.
SSH on my server sudo dig +short myip.opendns.com @resolver1.opendns.com
And use this IP in the WOPI box on NextCloud.
Just found the easy solution, assuming you run your nextcloud instance behind a router with port forwarding: just don´t set “use build in code server”! This will grab the external ip and lead to this problem. Instead:
is not a valid address. technically it would work with self-issued TLS certificates but such “solution” doesn’t scale for many devices, mobiles and external users.
If your connection fails bacause of the loop through the internet - search for “rebind protection”
if you want to keep the connection local search for splitbraindns
Yeah that works with selfsignet certificates (wich is checked by default).
Do i get the whole thing wrong? The nextcloud-office plugin connects to the codeserver-plugin running on the same host. The codeserver dont send data to the client so no need at all to expose that codeserver to the internet?