Unable to log in to web interface after upgrade to NC25

Support intro

Sorry to hear you’re facing problems :slightly_frowning_face:

help.nextcloud.com is for home/non-enterprise users. If you’re running a business, paid support can be accessed via portal.nextcloud.com where we can ensure your business keeps running smoothly.

In order to help you as quickly as possible, before clicking Create Topic please provide as much of the below as you can. Feel free to use a pastebin service for logs, otherwise either indent short log examples with four spaces:


Or for longer, use three backticks above and below the code snippet:


Some or all of the below information will be requested if it isn’t supplied; for fastest response please provide as much as you can :heart:

Nextcloud version (eg, 20.0.5): 25.0.0
Operating system and version (eg, Ubuntu 20.04): Arch Linux
Apache or nginx version (eg, Apache 2.4.25): 1.23.1
PHP version (eg, 7.4): 8.1.11

The issue you are facing:

Upgrade to version 25.0.0 had issues, first time I’ve ever had issues with a Nextcloud upgrade.

When running the web updater I encountered the message “Possible CSRF attack. Connection will be closed.” There was no way for me to update via the web updater. So I upgraded via occ which had no problems initially.

I was initially able to log into the web interface. After closing that particular session I can’t log in anywhere. I can access the login screen and input credentials, but the page just reloads with no error.

I’ve seen this behavior occasionally, but I’ve always been able to log in on a subsequent attempt. Now I can’t access the web interface at all. Server operations like file sync and webDAV calendar sync are still functioning without incident – I just can’t access the web interface.

This installation’s configuration hasn’t been touched for six months. It has been completely functional up until I upgraded to NC 25.

Only thing I did in the web interface before closing that last successful session was change the background from the default.

Web root is /srv/http. NGINX user is “http.” “http” user and group own everything in the web root. Other applications on the same server still run perfectly fine.

Is this the first time you’ve seen this error? (Y)

Steps to replicate it:

  1. Go to Nextcloud login page

  2. Input any username/password combo – even one intentionally wrong

  3. Login screen reloads, no error output, I get HTTP 500 Internal Server Error in the browser on the request for /core/img/app-background.jpg

The output of your Nextcloud log in Admin > Logging:

{"reqId":"jqaNVAvBHJRq3XeNtujT","level":0,"time":"2022-10-21T02:34:36+00:00","remoteAddr":"redacted","user":"--","app":"no app in context","method":"GET","url":"/nextcloud/apps/dashboard/","message":"Current user is not logged in","userAgent":"Mozilla/5.0 (Windows NT 10.0; rv:106.0) Gecko/20100101 Firefox/106.0","version":""

"reqId":"0lxTYaJUZgBUXGLi0ghK","level":3,"time":"2022-10-21T02:34:37+00:00","remoteAddr":"","user":"--","app":"index","method":"GET","url":"/core/img/app-background.jpg","message":"The requested uri(/core/img/app-background.jpg) cannot be processed by the script '/nextcloud/index.php')","userAgent":"Mozilla/5.0 (Windows NT 10.0; rv:106.0) Gecko/20100101 Firefox/106.0","version":""

The output of your config.php file in /path/to/nextcloud (make sure you remove any identifiable information!):

$CONFIG = array (
  'instanceid' => 'my instance id',
  'passwordsalt' => 'my passwordsalt',
  'secret' => 'my secret',
  'trusted_domains' =>
  array (
    0 => 'my host',
  'datadirectory' => '/srv/http/nextcloud/data',
  'dbtype' => 'mysql',
  'version' => '',
  'overwrite.cli.url' => 'my Nextcloud instances domain name',
  'dbname' => 'nextcloud',
  'dbhost' => 'localhost',
  'dbport' => '',
  'dbtableprefix' => 'oc_',
  'mysql.utf8mb4' => true,
  'dbuser' => 'nextcloud',
  'dbpassword' => 'my DB password',
  'installed' => true,
  'enable_previews' => false,
  'default_phone_region' => 'US',
  'memcache.local' => '\\OC\\Memcache\\APCu',
  'memcache.distributed' => '\\OC\\Memcache\\Redis',
  'memcache.locking' => '\\OC\\Memcache\\Redis',
  'redis' =>
   array (
    'host' => '/run/redis/redis.sock',
    'port' => '0',
    'password' => 'my Redis password',
  'maintenance' => false,
  'theme' => '',
  'loglevel' => 0,
  'updater.secret' => 'my updater secret',

The output of your Apache/nginx/system log in /var/log/____:

2022/10/20 22:01:53 [error] 20572#20572: *57 FastCGI sent in stderr: "PHP message: PHP Fatal error:  Uncaught Doctrine\DBAL\Exception: Failed to connect to the database: An exception occurred in the driver: SQLSTATE[HY000] [2002] No such file or directory in /srv/http/nextcloud/lib/private/DB/Connection.php:139

Solved myself after days of troubleshooting.

There is a part of the NGINX configuration given in the admin manual that doesn’t work properly anymore it seems, probably due to the theming changes in NC 25.

The 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;

For some reason (not an NGINX expert) this block’s rules concerning assets produce HTTP 500 errors whilst trying to log in. This is why I was getting 500 status codes for requests for “/core/img/app-background.jpg.” This block affects requests for assets and sends requests to a place that produces 500 errors that didn’t before for some reason. If this block is left in “nginx.conf” it will produce an HTTP 500, and the login screen will reload with the URL “?redirect_url=/nextcloud/apps/dashboard/” or something similar.

All I needed to do to solve the issue was to remove “jpg” from the first string. In my testing I’m able to keep the rest of the block in so long as I remove “jpg.”


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";


    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.

1 Like

I’m still not able to login, but I’m using Apache. This is what I get in the logs… it goes to login page, I put login and pass, and it goes back to login page…

remoteAddr":“”,“user”:“–”,“app”:“index”,“method”:“GET”,“url”:“/core/img/app-background.jpg”,“message”:“The requested uri(/core/img/app-background.jpg) cannot be processed by the script ‘/nextcloud/index.php’)”,“userAgent”:“Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.1 Safari/605.1.15”,“version”:“”,“exception”:{“Exception”:“Exception”,“Message”:“The requested uri(/core/img/app-background.jpg) cannot be processed by the script ‘/nextcloud/index.php’)”,“Code”:0,“Trace”:[{“file”:“/usr/share/webapps/nextcloud/lib/base.php”,“line”:985,“function”:“getRawPathInfo”,“class”:“OC\\AppFramework\\Http\\Request”,“type”:“->”,“args”:},{“file”:“/usr/share/webapps/nextcloud/index.php”,“line”:36,“function”:“handleRequest”,“class”:“OC”,“type”:“::”,“args”:}],“File”:“/usr/share/webapps/nextcloud/lib/private/AppFramework/Http/Request.php”,“Line”:733,“CustomMessage”:“–”}}

Any hints?