Open UltraBlackLinux opened 7 months ago
Try:
occ config:app:delete richdocuments canonical_webroot
Also your wopi_url
looks bogus:
"wopi_url": "https:\/\/domain.com\/cloud\/cloud\/custom_apps\/richdocumentscode\/proxy.php?req="
Try
Now I'm getting this error each time I try to access a document: Exception: Could not find urlsrc in WOPI
Also your wopi_url looks bogus
Yeah I noticed that as well, but that's like the opposite of what it's doing right now. I wonder what I should do about that...
That's progress I think. That exception indicates probably a problem with discovery, which is driven by the wopi_url
so let's fix that. It should be sufficient to go to Admin settings->Nextcloud Office then toggle from "Use the built-in CODE" to "Use your own server" then back to trigger the auto-populated value (I think - some recent changes were made here and not all of those are in the version of the app you're using; logging has been improved recently too but that's not in v8.2.x).
If not it can always be overridden via occ
.
that sadly didn't fix it. Now we're back to the missing custom web root...
In the browser or in the settings themselves?
What's the new occ config:list richdocuments
?
That's in the browser. it's making a 404 request, since it's missing the /cloud prefix
"public_wopi_url": "https:\/\/domain.com\/custom_apps\/richdocumentscode\/proxy.php?req=",
oh would you look at that. There is the culprit all of a sudden.
The other wopi url is still wrong but this is broken indeed.
Edit: I just managed to modify the public_wopi_url, and it's now correct (my browser is still making 404 requests, even after clearing the cache), but the wopi_url still keeps the second /cloud, even after setting it to the same value as public_wopi_url...
Edit 2: I just restarted nextcloud, got the url error again, toggled the built-in collabora server again, and now the values are back to the invalid defaults?? What is going on?
What does your apps_paths
look like from occ config:list system
?
"apps_paths": [
{
"path": "\/var\/www\/html\/apps",
"url": "\/apps",
"writable": false
},
{
"path": "\/var\/www\/html\/custom_apps",
"url": "\/custom_apps",
"writable": true
}
],
I've seen setups without that kind of separation, but I think I got most of my config file from the docker image I linked.
I just restarted nextcloud, got the url error again, toggled the built-in collabora server again, and now the values are back to the invalid defaults?? What is going on?
Unfortunately (well, fortunately really - but less so from a troubleshooting your situation perspective) the logic was drastically changed (improved, hopefully!) for the auto-configuration in #3315. Unfortunately you won't see that unless you're on NC28. But the recent changes also makes it challenging for me to keep straight in my head what could be going on in your particular case.
I've seen setups without that kind of separation, but I think I got most of my config file from the docker image I linked.
Yeah that's fine.
Maybe try this:
wopi_url
to be correct via occpublic_wopi_url
to be correct via occP.S. For the record, are you using the fpm Docker image + nginx (or something) or the apache Docker image?
- Manually set the
wopi_url
to be correct via occ
As I said previously, I seemingly cannot change that value. I set it, and when I check it, I see the old value again...
I'm getting the previously mentioned Could not find urlsrc in WOPI error regardless. It tries to access /apps/richdocuments/token
and instead gets an internal server error back. This only happens after I modify the public_wopi_url
P.S. For the record, are you using the fpm Docker image + nginx (or something) or the apache Docker image?
That is the apache image, yes
Edit: I just noticed that it's highlighting a few errors at once when clicking on the bottom urlsrc error, and this too: Trying to access array offset on value of type null at /var/www/html/custom_apps/richdocuments/lib/WOPI/DiscoveryManager.php#132
(line 130, 131, and 132)
I'm also seeing this error: GET https://domain.com/cloud/cloud/custom_apps/richdocumentscode/proxy.php?req=/hosting/capabilities resulted in a 404 Not Found
. There's the broken url that doesn't want to be changed.
You previously stated you're just using the standard Docker image, but that doesn't support subfolder based installations by default. Do you have a proxy in front / where is your external https URL actually terminating?
I am running caddy yeah.
I'm confused why you're saying that the image does not support that. The readme clearly states the instructions for a subfolder based installation (at least when using the apache image): https://github.com/docker-library/docs/blob/master/nextcloud/README.md#using-the-apache-image-behind-a-reverse-proxy-and-auto-configure-server-host-and-protocol
On top of that, I think my setup is the intended purpose for the Apache image, otherwise I don't think the TRUSTED_PROXIES
environment variable would make sense
I am running caddy yeah.
That's extremely important information.
The readme clearly states the instructions for a subfolder based installation (at least when using the apache image):
You're accessing NC via a subfolder path at the proxy level, but it's not actually installed in a subfolder.
As a result it's your proxy that is responsible for stripping the subfolder piece from the URL before proxying to Nextcloud.
The overwritewebroot
let's NC know to include the subfolder back where needed (when generating URLs for external use) so that things work, but NC shouldn't be getting passed URLs with the subfolder still in it by your proxy (since it's not actually a subfolder installation of NC).
You need to look at how to do that with Caddy. There are a couple ways. handle_path
and/or stri_prefix
come to mind.
This is all starting to make way more sense.
Subfolder installations of NC used to be really common (probably are a bit less today, but are still common enough). I was surprised to hear you were having such challenges using one.
But you actually aren't using a subfolder installation at all. :)
That's extremely important information. You're accessing NC via a subfolder path at the proxy level, but it's not actually installed in a subfolder. But you actually aren't using a subfolder installation at all. :)
Oh my bad, I'm sorry.
handle_path
I'm already using that, so I doubt my proxy's configuration is the culprit. I actually know that it is working. The first time I installed nextcloud, I actually got collabora working flawlessly (and I can't recall breaking my caddy config), but I accidentally killed the process, which corrupted the database, and one install later, it wasn't working anymore, and still isn't up to this day...
redir /cloud /cloud/ 308
handle_path /cloud/* {
reverse_proxy nextcloud:80
}
The
overwritewebroot
let's NC know to include the subfolder back where needed
This however doesn't explain why it's not letting me fix the public_wopi_url, and has one to many overwritewebroot prefixes in the wopi_url
I've just noticed something really weird about the /cloud/cloud problem. If I copy the correct public_wopi_url and modify it only slightly and try to use that for wopi_url, it takes the url without modifying it. What is going on? Why does that check even exist??
Here's some examples that work:
https://domain.com/cloud/custom_apps/richdocumentscode/proxy.php?reqa=
https://domain.com/cloud/custom_apps/richdocumentscode/proxy.php?req\\=
(it auto escapes a single backslash... sigh)https://domain.com/cloud/custom_apps/richdocumentscode/proxy.php?req
This gets converted back: https://domain.com/cloud/custom_apps/richdocumentscode/proxy.php?req=
any updates on this? I really want this to work and I still have no idea why it's not working for me...
Describe the bug I cannot get nextcloud to open files via collabora. Whenever it tries to do so, it completely ignores my specified webroot and thus hits a 404 (it tries to get
https://domain.com/custom_apps/richdocuments/...
instead ofhttps://domain.com/cloud/custom_apps/richdocuments/...
). It's been months since I first discovered this, but it still hasn't been fixed sadly.I've already tried using a standalone collabora server instead of the app, but no luck there either. The config has
To Reproduce Open a collabora document
Expected behavior It should apply a custom webroot, /cloud in my case.
Client details:
Server details
https://hub.docker.com/_/nextcloud/ (the official AIO image is a PITA to set up and has its fingers where I don't want them. Also kinda forces me to test on prod, so I'm not a fan)
Operating system: Arch linux
Web server: Whatever came with the docker image
Database: MariaDB
PHP version:
Nextcloud version: Whatever came with the docker image
Version of the richdocuments app latest, at this point it doesn't even seem to matter anymore... Version of Collabora Online also latest
Configuration of the richdocuments app
Logs
#### Nextcloud log (data/nextcloud.log) file too big? https://chonkyrabbit.eu/files/_share/SArXp-nextcloud.log #### Browser log ``` POST https://domain.com/custom_apps/richdocumentscode/proxy.php?req=/browser/f76e08a/cool.html?WOPISrc=https://domain.com/cloud/index.php/apps/richdocuments/wopi/files/1399_oc2zcelp23cu&title=/foovar.odp&lang=en&closebutton=1&revisionhistory=1 Status 404 Not Found VersionHTTP/2 Transferred918 B (643 B size) Referrer Policyno-referrer ```