Wanted to chime in:
I had nearly the same issue after updating to 25.0.0. If I’m reading this thread right you’re using Apache.
I was unable to login to the web interface after updating. I’d input my login info, and in response I’d just get a refreshed login screen with a different URL and an HTTP 500 for an asset. In my case the asset was “/core/img/app-background.jpg.”
Just as you – occ completely functional. No errors in logs, both Nextcloud and NGINX/Apache.
I fixed the problem by messing around with the NGINX configuration supplied in the admin manual. That configuration includes this block:
location ~ \.(?:css|js|svg|gif|png|jpg|ico|wasm|tflite)$ {
try_files $uri /nextcloud/index.php$request_uri;
expires 6M; # Cache-Control policy borrowed from `.htaccess`
access_log off; # Optional: Don't log access to assets
location ~ \.wasm$ {
default_type application/wasm;
}
}
I can reliably trigger and solve the issue at will by inserting/deleting this part of the NGINX config and deleting the reference to the file extension of the asset that’s the subject of the HTTP 500, in my case “jpg.” I can keep the rest of the config intact if I just delete the reference to “jpg.”
Based on how prevalent login issues seem to be on this forum after the release of NC 25 it would seem to me that there’s a bug pertaining to UI assets somewhere.
I can login without incident modifying my server configuration in the way I described and with these apps active:
Enabled:
- activity: 2.17.0
- bruteforcesettings: 2.5.0
- calendar: 4.0.1
- cloud_federation_api: 1.8.0
- contacts: 5.0.1
- contactsinteraction: 1.6.0
- dashboard: 7.5.0
- dav: 1.24.0
- federatedfilesharing: 1.15.0
- files: 1.20.1
- files_pdfviewer: 2.6.0
- files_rightclick: 1.4.0
- files_trashbin: 1.15.0
- files_versions: 1.18.0
- logreader: 2.10.0
- lookup_server_connector: 1.13.0
- nextcloud_announcements: 1.14.0
- notifications: 2.13.1
- oauth2: 1.13.0
- password_policy: 1.15.0
- photos: 2.0.0
- privacy: 1.9.0
- provisioning_api: 1.15.0
- related_resources: 1.0.1
- serverinfo: 1.15.0
- settings: 1.7.0
- suspicious_login: 4.3.0
- text: 3.6.0
- theming: 2.0.0
- twofactor_backupcodes: 1.14.0
- updatenotification: 1.15.0
- viewer: 1.9.0
- weather_status: 1.5.0
- workflowengine: 2.7.0
I think the only relevant apps in this case are dashboard and theming. I did update related-resources to 1.0.1 before fixing my issue, but I didn’t see any change from updating.
EDIT:
Upon further investigation the NGINX configuration in the admin manual actually changed slightly from what was supplied when I set up this instance in May this year.
Prior to NC 24 the NGINX configuration contained the location block I described above. From NC 24 onwards the manual was changed to include
# Set the `immutable` cache control options only for assets with a cache busting `v` argument
map $arg_v $asset_immutable {
"" "";
default "immutable";
}
and
location ~ \.(?:css|js|svg|gif|png|jpg|ico|wasm|tflite|map)$ {
try_files $uri /index.php$request_uri;
add_header Cache-Control "public, max-age=15778463, $asset_immutable";
access_log off; # Optional: Don't log access to assets
location ~ \.wasm$ {
default_type application/wasm;
}
}
Using this updated configuration makes the login issue disappear with the entire location block intact. So it would seem this issue is not a bug in Nextcloud but that changes were made in NC 24/25 that necessitate a change in web server configurations, and existing users would not know to change their configurations until they encounter the issue and/or happen to stumble upon the changes in the manual.
