Closed quenenni closed 4 months ago
I forgot to mention that I can enable / disabel apps with the occ command and the cloud and apps are working good (as mush as I can tell).
The problem is only from the web interface.
Content-Security-Policy : Les paramètres de la page ont empêché le chargement d’une ressource à https://cloud.yyyyy.be:4431/apps/files/ (« connect-src »).
This is the source of your seeing the unstable error message. The app stability check runs from your browser and CSP is blocking this check so it by definition fails. I suspect you don't wish the :4431
to be in your URL.
Set the appropriate overwrite*
parameters in your config (i.e. without the port) and see if the problem goes away.
I suspect it will, but let us know if not.
Very good catch. I completely missed that wrong port number there. Thank you. Indeed, it should be 443 or no port.
I set all the overwrite* params, but no luck, the errors are still the same.
'overwrite.cli.url' => 'https://cloud.yyyyy.be/', <- already present
'overwriteprotocol' => 'https',
'overwritehost' => 'cloud.yyyyy.be:443',
'overwritewebroot' => '/',
I tried to play with the option fastcgi_param SERVER_PORT 443;
in my Nginx vhost, but also no luck (I remebered having a similar issue couple years ago and that param fixed it at the time).
More possibly related reports on the forum: https://help.nextcloud.com/t/this-app-cannot-be-enabled-because-it-makes-the-server-unstable-error/187233/5
same to me and I already did what @quenenni also did with no luck
I have the same problem since v28.0.4 and I can confirm this is because of a CSP error.
In my case overwriteprotocol => https
seems to be ignored.
The app-install-page queries http://<domain>/apps/files/
that fails because of the policy connect-src self
, that would require https://<domain>/apps/files/
.
On nixos and I also have this issue, I get this CSP error in the firefox console when I try enable any app:
Don't know why it's trying to talk to that url 🤷🏻♀️
I found such a CSP error in my browser's console too. It seems some specific part that controls overwriting the URL is malfunctioning after v28.0.4.
true for 49 rc 4 as well
The URL is generated from the frontend, so the overwriteprotocol
is not taken into account, but the current protocol is used.
But in this specific case the protocol is never set, the request is done to a relative URL, so this should always work.
But those of you that have Nextcloud installed into the root of your (sub) domain, could you try setting overwritewebroot
to an empty string?
Please report if you have currently overwritewebroot
set and if it works if you set overwritewebroot => ''
.
But those of you that have Nextcloud installed into the root of your (sub) domain, could you try setting
overwritewebroot
to an empty string? Please report if you have currentlyoverwritewebroot
set and if it works if you setoverwritewebroot => ''
.
I did and no luck.
@susnux - regarding the URL, let me share the following observation about the requests that happen right after I push an app's activation button:
So, the first GET uses HTTPS, but it just redirects to almost the same URL, but with HTTP. Note that the redirect does add a /
to the end of the URL.
And it's that second (HTTP-based) GET that fails.
Unfortunately, the Nextcloud installation that I'm dealing with is hosted, so I don't have access to the Nginx configuration. But I assume than Nginx, just like Apache's mod_dir
, has an option to correct directory URLs that lack the final /
.
Maybe that has something to do with it? Maybe things would work, if the first GET had the trailing /
and would thus succeed without a redirect?
I'm having the same issue, and I'm using the community helm chart (nextcloud/helm here on github).
What I'm seeing is what @uncle-betty is describing. The GET to https://domain/apps/files gets redirected to http://domain/apps/files/ (with a 301, and note that it redirects to http and not https). None of the overwrite options is making any difference.
From the nextcloud-nginx and nextcloud-fpm containers I can see that it seems like nextcloud-nginx is the one responding with the 301. I don't see anything other than 200 responses from the nextcloud-fpm container.
Curiously I can't find any redirects in the nginx config that should cause this.
It can be solved by adding "absolute_redirect off;" in the server section in the nginx config, but I don't know what the root cause is. (I.e. I'm not sure what causes the redirect in the first place)
So this is not a bug, but a configuration issue, you are using a proxy / reverse proxy that does not correctly rewrites redirects.
This sounds like following problem:
/
(Apache does this with the default config)So in this case your webserver returns a 301 with http://server/apps/files/
, your reverse proxy does not rewrite it to 301 with https://server/apps/files/
.
Solution: Ensure redirects are rewritten using the correct protocol on your reverse proxy.
For NGinx e.g. ensure to use proxy_redirect
.
Note: If you use proxy_pass
this is the default, EXCEPT you use variables in the proxy_pass
.
For other reverse proxies, refer to their documentation.
If you can not access the reverse proxy, maybe disabling DirectorySlash
of Apache could help.
@susnux Not so sure about this. The feature worked perfectly in the 3 version and stopped working in the 4 version without any changes in the proxy (traefik) settings. Please review.
So this is not a bug, but a configuration issue, you are using a proxy / reverse proxy that does not correctly rewrites redirects.
This sounds like following problem:
* Your webserver is running on HTTP * Your webserver adds a 301 with added `/` (Apache does this with the default config) * You use a reverse proxy with HTTPS * You have not configured your reverse proxy to correctly adjust redirects
So in this case your webserver returns a 301 with
http://server/apps/files/
, your reverse proxy does not rewrite it to 301 withhttps://server/apps/files/
.Solution: Ensure redirects are rewritten using the correct protocol on your reverse proxy. For NGinx e.g. ensure to use
proxy_redirect
. Note: If you useproxy_pass
this is the default, EXCEPT you use variables in theproxy_pass
.For other reverse proxies, refer to their documentation.
If you can not access the reverse proxy, maybe disabling
DirectorySlash
of Apache could help.
While I can agree it's a configuration issue, it's an issue with the recommended nginx configuration. Perhaps a documentation bug, as well as a bug for the helm chart (since the helm chart bundles the recommended configuration as default)?
In any case, I'm not sure I agree that it's the job of the reverse proxy to fix it. It's just for this very specific request things seems to go wrong. But I suppose that's a matter of taste. (I'm fairly sure Traefik needs third party plugins to rewrite responses. It's not something I've ever needed to do)
Not so sure about this. The feature worked perfectly in the 3 version and stopped working in the 4 version without any changes in the proxy (traefik) settings. Please review.
Yes because the check was not running. We fixed this for 28.0.4.
And as you can see from the requests the protocol is incorrect, you can test it by your own with curl -X GET -i https://your-sever/apps/files
.
In any case, I'm not sure I agree that it's the job of the reverse proxy to fix it. It's just for this very specific request things seems to go wrong
No and it is, Nextcloud does not trigger the redirect here. It is triggered by your webserver, then the reverse proxy must handle the redirect correctly, or you disable those redirects on the webserver - what ever you prefer. The webserver does not know about the reverse proxy, so the reverse proxy needs to fixup any redirects directly coming from the webserver.
You could also set up the rewrite base like here: https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/config_sample_php_parameters.html#htaccess-rewritebase
If you set it to /
the index.php
will be removed and Nextcloud sets DirectorySlash off
, this is probably why you do not suffer this issue when using the community docker image.
Yes, that was my conclusion as well, but my point was just that my webserver is nginx configured exactly as recommended by the Nextcloud documentation.
From NGinx documentation:
If a location is defined by a prefix string that ends with the slash character, and requests are processed by one of proxy_pass, fastcgi_pass [...] then the special processing is performed. In response to a request with URI equal to this string, but without the trailing slash, a permanent redirect with the code 301 will be returned to the requested URI with the slash appended.
This is normally not a problem, as your reverse proxy normally also handles the rewrite (see e.g. nginx default behavior of proxy_redirect
).
ignore that post, sorry. Didn't see a fix is queued. Will delete this post soon.
Hmmm, the statements above don't help. Interesting is what I get as an answer for: GET https://nct.domain.de/apps/files: ... location: http://nct.domain.de/apps/files ... http instead of https?
Thanks @susnux for the explanation!
I had this same issue and use Nginx as a reverse proxy with a variable in proxy_pass
(HTTPS) and another Nginx as webserver (HTTP) for Nextcloud. Because Nginx doesn't automatically set the proxy_redirect default
value when you use variables in proxy_pass
I had to add proxy_redirect http://$host https://$host;
to my Nginx reverse proxy (I added it below the proxy_pass
line in my Nginx reverse proxy location
block that points to the Nginx webserver).
Hello,
we tried to backport proposed fix into our existing affected Nextcloud container, but it doesn't seems to fix the issue. The original problem as reported still persists.
also, the patches deployed yesterday for NC28 didn't fix the issue.
Am 26. April 2024 um 09:35 schrieb "litinoveweedle" @.***>:
Hello,
we tried to backport https://github.com/alexbelgium/hassio-addons/issues/1333#issuecomment-2077651181 proposed fix https://github.com/nextcloud/server/pull/44939 into our existing affected Nextcloud container, but it doesn't seems to fix the issue. The original problem as reported still persists https://github.com/alexbelgium/hassio-addons/issues/1333#issuecomment-2077734641 .
—
Reply to this email directly, view it on GitHub https://github.com/nextcloud/server/issues/44685#issuecomment-2078805514 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ABRYV7RYEZAIBJS6U32XVOTY7H7VLAVCNFSM6AAAAABFZI4NACVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANZYHAYDKNJRGQ .
You are receiving this because you commented.
To collect more data, I played around with an override that let me modify the JavaScript my browser receives from the managed Nextcloud 28.0.4 instance I'm dealing with.
The original code generates the URL from apps/files
, which triggers the issue.
Using an override generates the URL from apps/files/
instead also triggers the issue. As I understand it, this is equivalent to the fix that was rolled out.
Using an override that generates the URL from /settings/apps/files
works.
Using an override that generates the URL from /settings/apps/files/
also works.
The latter two requests, the ones that are based on a URL built from an absolute path, don't result in a 301 redirect.
Wait... let me step back here for a second and make sure that I'm making the right assumptions here: Where should the first GET request actually go? /apps/files
or /settings/apps/files
?
Because in 28.0.4 with and without our non-working "fix", the first GET goes to /apps/files/
and /apps/files
, respectively.
So, apps/files
is supposed to be relative to which base path? /
or /settings
?
If it's /settings
, then that's the real issue here, I'd say. We were just distracted from it, because besides /settings/apps/files
, there's also /apps/files
, isn't there? And going to /apps/files
causes the 301 redirect. But the fix then would not be to avoid the redirect. Instead, it would be make the initial GET request to /settings/apps/files
.
Additionally, my browser console shows something like:
Mixed Content: The page at 'https://testserver.mydomain.de/settings/apps/disabled' was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint '... This request has been blocked; the content must be served over HTTPS.
while all links on that page contain the /settings/ , like
https://testserver.mydomain/settings/apps/disabled/dicomviewer
One last observation: It doesn't seem to be about the absolute paths.
When I apply an override that generates the GET URL from settings/apps/files
, then this works, too.
Note that this would be consistent with the successful POST whose URL is generated from settings/apps/enable
(and which precedes the failing GET).
Where should the first GET request actually go?
/apps/files
or/settings/apps/files
?
/apps/files
should be fetched. Because if the files app fails then the installed app crashed something internally.
As written already above, if you have this error, then:
If you use nginx as reverse proxy, refer to this on how to fix your configuration: https://github.com/nextcloud/server/issues/44685#issuecomment-2067314656
No / to be seen. Redirect works, but with 302. I get same site errors in the browser console pointing to the AppStore:
Die Ressource unter "https://usercontent.apps.nextcloud.com/aHR0cHM6Ly9yYXcuZ2l0aHVidXNlcmNvbnRlbnQuY29tL25leHRjbG91ZC9pbnRlZ3JhdGlvbl9ub3Rpb24vbWFpbi9zY3JlZW5zaG90cy9zY3JlZW5zaG90MS5qcGc=" wurde aufgrund ihres Cross-Origin-Resource-Policy-Headers (oder dessen Fehlens) blockiert. Weitere Informationen unter https://developer.mozilla.org/docs/Web/HTTP/Cross-Origin_Resource_Policy_(CORP)#
Because it is a CORS header issue, Safari ignores this restriction and all works fine. Next step is to identify the needed setting in my traefik.
@joergmschulz yes thats exactly the error already discussed here:
/apps/files
so a request to https://your-domain/apps/files
is issued.http://your-proxy/apps/files
(note now the protocoll is HTTP (not HTTPS))302 http://your-proxy/apps/files/
Solution: Disable mod_dir
if you use Apache, or enable rewriting redirects in your reverse proxy.
@susnux Obviously, nginx supports rewriting headers which isn't supported in traefik, see https://github.com/traefik/traefik/issues/5809. Quoting:
It is worth noting that the http / https case is often corrected by Traefik passing X-Forwarded-Proto: https to the backend service so it knows that the "true" protocol is https (and can issue redirects as such). For services not handling X-Forwarded-Proto (which is in the spec that I mention above), then yes your point is spot on.
Posting here, but related to the docker compose fpm variant (the issue there points here). This is indeed proxy bug.
[!WARNING] The info below is more of a copy/paste from my working setup, but it should be taken with grain of salt. I can't provide a working example for all the proxies out there and their variants. On my setup it works fine, but I am not willing to be responsible if someone breaks his setup using the code below. Read first, check with your setup then edit files and restart containers.
A workaround for nginx-proxy-manager is to map the default proxy.conf and add the line proposed above for proxy_redirect, i.e.
1) Copy the /etc/nginx/conf.d/include/proxy.conf
out from the container and mount it locally
volumes:
- ./data:/data
- ./letsencrypt:/etc/letsencrypt
- ./proxy.conf:/etc/nginx/conf.d/include/proxy.conf
and put this line at the end of the proxy.conf file:
proxy_redirect http://$host https://$host;
A workaround for nginx-proxy :
This might vary, but pasting my own setup here. Find and copy nginx.tmpl
from the container to the outside and map it as volume. Usually the file is found as /app/nginx.tmpl
in the nginx-proxy container.
services:
nginx-proxy:
<snip>
volumes:
- ./nginx.tmpl:/app/nginx.tmpl
- /var/run/docker.sock:/tmp/docker.sock:ro
Edit the template location as follows :
location {{ .Path }} {
{{ if eq .NetworkTag "internal" }}
# Only allow traffic from internal clients
include /etc/nginx/network_internal.conf;
{{ end }}
{{ if eq .Proto "uwsgi" }}
include uwsgi_params;
uwsgi_pass {{ trim .Proto }}://{{ trim .Upstream }};
{{ else if eq .Proto "fastcgi" }}
root {{ trim .VhostRoot }};
include fastcgi_params;
fastcgi_pass {{ trim .Upstream }};
{{ else if eq .Proto "grpc" }}
grpc_pass {{ trim .Proto }}://{{ trim .Upstream }};
{{ else }}
proxy_pass {{ trim .Proto }}://{{ trim .Upstream }}{{ trim .Dest }};
proxy_redirect http://{{ trim .Upstream }} https://{{ trim .Upstream }};
{{ end }}
{{ if (exists (printf "/etc/nginx/htpasswd/%s" .Host)) }}
auth_basic "Restricted {{ .Host }}";
auth_basic_user_file {{ (printf "/etc/nginx/htpasswd/%s" .Host) }};
{{ end }}
{{ if (exists (printf "/etc/nginx/vhost.d/%s_%s_location" .Host (sha1 .Path) )) }}
include {{ printf "/etc/nginx/vhost.d/%s_%s_location" .Host (sha1 .Path) }};
{{ else if (exists (printf "/etc/nginx/vhost.d/%s_location" .Host)) }}
include {{ printf "/etc/nginx/vhost.d/%s_location" .Host}};
{{ else if (exists "/etc/nginx/vhost.d/default_location") }}
include /etc/nginx/vhost.d/default_location;
{{ end }}
}
{{ end }}
Note the line
proxy_redirect http://{{ trim .Upstream }} https://{{ trim .Upstream }};
Save, and restart/rebuild the containers and keep in mind while this works on my setup, it might not be the same on yours.
Tested on 4 instances running Nextcloud 29 via Docker. For other setups the workaround is the same, you need to figure out the location of the proxy_pass
directive and just add proxy_redirect
with the correct settings below it.
@joergmschulz yes that is why I recommended that if your reverse proxy is not capable of rewriting redirects, then you can also disable the redirect within the web server, e.g. if you use Apache then set DirectorySlash Off
yes - it's rather the rewriting of the location header in the answer. Indeed, traefik doesn't do this. Trying to switch to nginx for the test environment ....
This issue is caused by the following parameter that enables "pretty urls" (aka /index.php/apps/files can be reached by /apps/files) and might not be aware of the reverse-proxies in front of it. Disabling it can fix the issue right away, but leaves us with ugly URLs:
fastcgi_param front_controller_active true
In my case, i had a completely different approach instead. Since my setup was php-fpm -> Nginx (static webserver) -> haproxy (ssl terminator), i fixed it with the following directive in my haproxy backend (which i believe is the most semantically correct approach):
http-response replace-value Location (http:\/\/)(.*) https://\2
Be careful, though, as this will also rewrite external redirects and might not be your wanted behaviour.
in traefik a workaround looks like:
- "traefik.http.middlewares.nctredirect.redirectregex.regex=(http.?://)my.nc.de/apps/files$"
- "traefik.http.middlewares.nctredirect.redirectregex.replacement=https://my.nc.de/index.php/apps/files"
- traefik.http.middlewares.nctredirect.redirectregex.permanent=true
Just for those who are running nextcloud in (Rancher-made) K8s the self made way like this: -> Default nginx Ingress Controller as Reverse Proxy from (Rancher-made) K8s -> nginx pod / container as web server in front of... -> ...nextloud-fpm container
The default behaviour of the nginx Ingress Controller is "proxy_redirect off". To change this and so make nextclouds check request to the files app (with "wrong" set "HTTP" instead of "HTTPS" in the Location URL) work again after enabling an app just add these annotations to the Ingress Object:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: nextcloud
annotations:
nginx.ingress.kubernetes.io/proxy-redirect-from: http://$host <-- ADD THIS
nginx.ingress.kubernetes.io/proxy-redirect-to: https://$host <-- ADD THIS
spec:
rules:
[...]
In my setup this let the check request work again and so apps can be enabled via the GUI
front_controller_active
Will there be a proper fix to this issue? Some updated Nginx config maybe without the need to disable pretty urls
Yes, this needs to be fixed. This is a blocker for running Nextcloud.
Ok, this is NOT working per bug #678
BUT, IS working for the latest version of the v28 series looks like: 28.0.9.1
Attaching my docker-compose.yml and hope this helps anyone:
⚠️ This issue respects the following points: ⚠️
Bug description
Since I upgraded a cloud from v27.1.3 to v28.0.4, I can't enable /disable any of the apps in the cloud. Every attempt shows me this error msg: "This app cannot be enabled because it makes the server unstable"
Steps to reproduce
Expected behavior
Apps are activated / desactivated.
Installation method
Community Manual installation with Archive
Nextcloud Server version
28
Operating system
Debian/Ubuntu
PHP engine version
PHP 8.1
Web server
Nginx
Database engine version
MariaDB
Is this bug present after an update or on a fresh install?
Upgraded to a MAJOR version (ex. 22 to 23)
Are you using the Nextcloud Server Encryption module?
Encryption is Disabled
What user-backends are you using?
Configuration report
List of activated Apps
Nextcloud Signing status
Nextcloud Logs
Additional info
I upgrade other clouds on another server from v27.1.3 to v28.0.4 and there, no problem to enable / disable the apps. Server has the same configuration as the one with the problems (Debian / php / mariadb / nginx).
The only thing (I see) that is different, is the Haproxy I'm using in front of Nginx on the server with the problems.
The Nginx log shows the POST request to enable the app and gives a 200 return code:
In the Firefox console, I have this error each time I try to enable / disable an app:
My haproxy config is using the tcp mode, so https is managed by Nginx:
The content of the file routes.map is:
My Nginx config is very much like the one from the doc (https://docs.nextcloud.com/server/latest/admin_manual/installation/nginx.html):