[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 |
|
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. |
|
in traefik a workaround looks like: |
|
Just for those who are running nextcloud in (Rancher-made) K8s the self made way like this: 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: In my setup this let the check request work again and so apps can be enabled via the GUI |
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: |
|
I still have this problem with NC 30. It is still the CSP thing. It worked before the update. And I don't understand, what changed in the was I enable or disable apps. |
|
CSP? Did your config.php change? |
|
I can't change the config.php. I just clicked the update. |
|
Think you should open a new bug for v30 |
|
See #48040 |
I use the fpm variant too and build my web container and the Nextcloud container myself with the given Dockerfile and configs. In NC29 I didn't realize this problem but now in NC30 I have the same and wonder why. I didn't change anything. I'm running NGINX Proxy Manager and have a proxy host set up there. This hacky trick of you cannot be the solution... |
I just tested using NC 30 and Deck app, and it installed properly. Still using the config for nginx-proxy-manager as showin in my reply. Are you sure there's no other problems ? Did you check your logs / nginx configuration ? I suggest a review on your nginx conf on the Nextcloud side, because that thing changed since NC29. I would also suggest you post your issue on the docker section, because this one is already closed. |
|
I just installed the 30.0.1 update and everything seems to be working again. Now I am curious:
How can a Nextcloud update fix an incorrect reverse proxy configuration? |
We did not fix the wrong configuration but applied a workaround, by preventing a potential redirect. Yet any other app could rely on this valid bahavior so you could have similar problems in other apps. |
|
This ticket was resolved with 28.0.8, 29.0.3 and 30.0.1. |
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: