Passwordsalt missing from config.php

Nextcloud version:
Operating system and version: Qnap docker
PHP version: 8.1.11

I upgraded from the lastest 24 point release to 25 via docker-compose pull and now I get a message that ‘passwordsalt’ is not correctly configured in config.php. It seems passwordsalt is now a required setting.

It was working in 24

The error message

Die erforderliche passwordsalt Konfigurationsvariable ist in der config.php nicht konfiguriert.
Bitte deinen Server-Administrator, die Nextcloud-Konfiguration zu überprüfen.

This should corrspond to

The required passwordsalt config variable is not configured in the config.php file.

I don’t have a passwordsalt setting, so I do not know what I should put there.

Can someone please help me?

Is this the first time you’ve seen this error?_:Y

Steps to replicate it:

  1. install latest 24 via the official dockerhub nextcloud image
  2. use a config.php without passwordsalt or empty passwordsalt
  3. upgrade to 25
$CONFIG = array (
  'overwrite.cli.url' => 'https://my new domain',
  'overwriteprotocol' => 'https',
  'datadirectory' => '/var/www/html/data',
  'dbtype' => 'mysql',
  'version' => '',
  'dbname' => 'nextcloud',
  'dbhost' => 'db:3306',
  'dbtableprefix' => 'oc_',
  'dbuser' => 'nextcloud',
  'dbpassword' => 'mypassword',
  'installed' => true,
  'instanceid' => 'some number',
  'maintenance' => false,
  'theme' => '',
  'forcessl' => true,
  'trusted_domains' => 
  array (
    0 => 'my old domain',
    1 => 'my new domain,
  'trusted_proxies' => 
  array (
    0 => 'ip of the nas',
    1 => 'localhost',
  'overwritehost' => 'my new domain',
  'share_folder' => '/Shared',
  'secret' => 'long string',
  'loglevel' => 0,
  '' => 'stable',
  'htaccess.RewriteBase' => '/',
  'memcache.local' => '\\OC\\Memcache\\APCu',
  'memcache.locking' => '\\OC\\Memcache\\Redis',
  'filelocking.enabled' => true,
  'redis' => 
  array (
    'host' => 'cache',
    'port' => 6379,
    'password' => 'my redis pw',
  'apps_paths' => 
  array (
    0 => 
    array (
      'path' => '/var/www/html/apps',
      'url' => '/apps',
      'writable' => false,
    1 => 
    array (
      'path' => '/var/www/html/custom_apps',
      'url' => '/custom_apps',
      'writable' => true,
  'mail_smtpmode' => 'smtp',
  'mail_smtphost' => 'mail',
  'mail_smtpport' => '25',
  'mail_sendmailmode' => 'smtp',
  'mail_domain' => 'my mail domain',
  'mail_from_address' => 'robot',
  'default_phone_region' => 'AT',
  'mysql.utf8mb4' => true,

In the log files I don’t see an error.

If I remove ‘passwordsalt’ from

I can at least log in again, but it would be great to know how to fix this issue.

I am facing the same issue after updating a regular server installation.

Should I report this as a bug?

The bug: [Bug]: passwordsalt migration missing · Issue #34780 · nextcloud/server · GitHub

Yes me too, after upgrading from 24 to 25, I’m no longer able to login because of the missing passwordsalt on m y config.php which it was working fine before the upgrade.

Closing here. Please stay at the GitHub topic. There are more news already.

Honestly, neither the GitHub issue nor the thread here is it really clear about whether the password salt was ever present on the affected instances, even though it seems that this clearly has to be the case, according to the documentation:

‘passwordsalt’ => ‘’,

The salt used to hash all passwords, auto-generated by the Nextcloud installer. (There are also per-user salts.) If you lose this salt you lose all your passwords. This example is for documentation only, and you should never use it.

Also, the passwordsalt variable is a thing that goes all the way back to the OwnCloud days, so the only reasonable explenation for this issue would be, that it either was deleted by the user or during the upgrade process. However, at least the WebUpdater or a manual upgrade, following the official documentation, doesn’t seem to remove it. So I wonder what the various (build) scripts out there and / or the users are doing these days… :wink:

Ok, as soon as the GH issue is solved we should improve the docs.
Would you mind adding an issue at the docs repo?

Sorry I’m not sure what you mean. The curved text snippet in my post is actually from the documentation. And it says clearly that the password salt is generated by the installer and should not be changed.

So if an instance suddenly is missing the password salt, it either never existed on this instance, which I highly doubt , or the users have deleted it themself or some script has deleted it. I upgrade the same instance for years ( since NC14? ) and never had an issue like that, so I wouldn’t blame the documentation, but maybe the affected users, or more likely some script that is building the Docker containers or an upgrade script in a VM etc…

EDIT: Ok. According to the GitHub issue it looks like that there actually were working instances that didn’t have a password salt in the config.php. I have no idea why this the case, but unless these instances were set up manually by using the installer from the zip file, and / or the password salt officially became obsolete, there is probably no need to change the documentation…?

This topic was automatically closed after 11 hours. New replies are no longer allowed.

Hey @bb77 ,

after re-reading my post it was probably too late for me on this day :wink:

Hi :wave:

I have a problem similar to this. My upgraded nextcloud is complaining about:

The required secret config variable is not configured in the config.php file.

I tried setting a secret variable in the config. Made it impossible to login as do to:

Message: HMAC does not match.

I tried to build a new container image where I removed the secret from the foreach statement suggested in this thread. Where I still have:

The required secret config variable is not configured in the config.php file.

Any suggestions on what to do next ?


Please take a look here - I have simply modified source code as quick workaround (it is strange that it is not working for you; please check it again, maybe restart web server etc.).

BTW. Adding secret was causing the same issue (“HMAC does not match”) as on your instance.