-
Notifications
You must be signed in to change notification settings - Fork 115
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
richdocuments ignores custom webroot #3420
Comments
Try:
Also your
|
Now I'm getting this error each time I try to access a document:
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 If not it can always be overridden via |
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 |
That's in the browser. it's making a 404 request, since it's missing the /cloud prefix 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 |
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. |
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.
Yeah that's fine. Maybe try this:
P.S. For the record, are you using the fpm Docker image + nginx (or something) or the apache Docker image? |
As I said previously, I seemingly cannot change that value. I set it, and when I check it, I see the old value again...
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: I'm also seeing this error: |
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 |
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. As a result it's your proxy that is responsible for stripping the subfolder piece from the URL before proxying to Nextcloud. The You need to look at how to do that with Caddy. There are a couple ways. 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. :) |
Oh my bad, I'm sorry.
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...
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:
This gets converted back: |
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
The text was updated successfully, but these errors were encountered: