[Bug]: Can't enable or disable apps after upgrade to v28.0.4 #44685
Comments
quenenni
added
0. Needs triage
|
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. |
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 Set the appropriate I suspect it will, but let us know if not. |
|
Very good catch. I completely missed that wrong port number there. Thank you. I set all the overwrite* params, but no luck, the errors are still the same. I tried to play with the option |
|
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 |
|
On nixos and I also have this issue, I get this CSP error in the firefox console when I try enable any app: |
|
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 |
|
But those of you that have Nextcloud installed into the root of your (sub) domain, could you try setting |
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 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 Maybe that has something to do with it? Maybe things would work, if the first GET had the trailing |
|
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:
So in this case your webserver returns a 301 with Solution: Ensure redirects are rewritten using the correct protocol on your reverse proxy. For other reverse proxies, refer to their documentation. If you can not access the reverse proxy, maybe disabling |
|
@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. |
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) |
Yes because the check was not running. We fixed this for 28.0.4.
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. You could also set up the rewrite base like here: If you set it to |
From NGinx documentation:
This is normally not a problem, as your reverse proxy normally also handles the rewrite (see e.g. nginx default behavior of |
|
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: |
|
Thanks @susnux for the explanation! I had this same issue and use Nginx as a reverse proxy with a variable in |
|
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 alexbelgium/hassio-addons#1333 (comment) proposed fix #44939 into our existing affected Nextcloud container, but it doesn't seems to fix the issue. The original problem as reported still persists alexbelgium/hassio-addons#1333 (comment) .
—
Reply to this email directly, view it on GitHub #44685 (comment) , 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 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? Because in 28.0.4 with and without our non-working "fix", the first GET goes to So, If it's |
|
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 Note that this would be consistent with the successful POST whose URL is generated from |
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: |
|
No / to be seen. 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:
Solution: Disable |
|
@susnux Obviously, nginx supports rewriting headers which isn't supported in traefik, see traefik/traefik#5809. Quoting: |
|
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.
volumes:
- ./data:/data
- ./letsencrypt:/etc/letsencrypt
- ./proxy.conf:/etc/nginx/conf.d/include/proxy.confand put this line at the end of the proxy.conf file: proxy_redirect http://$host https://$host;A workaround for nginx-proxy : services:
nginx-proxy:
<snip>
volumes:
- ./nginx.tmpl:/app/nginx.tmpl
- /var/run/docker.sock:/tmp/docker.sock:roEdit 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 |
|
@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 |
|
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:
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):
Be careful, though, as this will also rewrite external redirects and might not be your wanted behaviour. |
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
{ "system": { "trusted_domains": [ "cloud.yyyyy.be", "cloud.yyyyy2.be" ], "activity_expire_days": 30, "appstoreenabled": true, "appstore.experimental.enabled": false, "auth.bruteforce.protection.enabled": true, "default_phone_region": "be", "datadirectory": "***REMOVED SENSITIVE VALUE***", "data-fingerprint": "", "dbhost": "***REMOVED SENSITIVE VALUE***", "dbname": "***REMOVED SENSITIVE VALUE***", "dbpassword": "***REMOVED SENSITIVE VALUE***", "dbtableprefix": "", "dbtype": "mysql", "dbuser": "***REMOVED SENSITIVE VALUE***", "default_language": "fr", "hashingCost": 10, "htaccess.RewriteBase": "\/", "installed": true, "instanceid": "***REMOVED SENSITIVE VALUE***", "integrity.check.disabled": true, "localstorage.allowsymlinks": true, "logfile": "\/var\/log\/nextcloud\/yyyyy.log", "loglevel": 2, "logtimezone": "Europe\/Brussels", "mail_domain": "***REMOVED SENSITIVE VALUE***", "mail_from_address": "***REMOVED SENSITIVE VALUE***", "mail_smtphost": "***REMOVED SENSITIVE VALUE***", "mail_smtpmode": "sendmail", "maintenance": false, "memcache.distributed": "\\OC\\Memcache\\Redis", "memcache.local": "\\OC\\Memcache\\APCu", "memcache.locking": "\\OC\\Memcache\\Redis", "redis": { "host": "***REMOVED SENSITIVE VALUE***", "port": 0, "dbindex": 1, "timeout": 1.5 }, "minimum.supported.desktop.version": "2.1.0", "mysql.utf8mb4": true, "passwordsalt": "***REMOVED SENSITIVE VALUE***", "preview_libreoffice_path": "\/usr\/bin\/libreoffice", "preview_max_filesize_image": 10, "secret": "***REMOVED SENSITIVE VALUE***", "simpleSignUpLink.shown": false, "trashbin_retention_obligation": "auto, 30", "updatechecker": true, "upgrade.disable-web": true, "version": "28.0.4.1", "versions_retention_obligation": "auto, 90", "overwrite.cli.url": "https:\/\/cloud.yyyyy.be\/", "theme": "", "mail_sendmailmode": "smtp", "maintenance_window_start": 2, "app_install_overwrite": [ "bbb" ], "trusted_proxies": "***REMOVED SENSITIVE VALUE***" } }List of activated Apps
Nextcloud Signing status
Nextcloud Logs
Nothing in Nextcloud log with loglevel to 0Additional 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):
The text was updated successfully, but these errors were encountered: