[Bug]: Nextcloud always changes the MySQL db password

[Ma27]

⚠️ This issue respects the following points: ⚠️

• [X] This is a bug, not a question or a configuration/webserver/proxy issue.
• [X] This issue is not already reported on Github (I've searched it).
• [X] Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
• [X] Nextcloud Server is running on 64bit capable CPU, PHP and OS.
• [X] I agree to follow Nextcloud's Code of Conduct.

Bug description

Since #33513 Nextcloud always recreates the MySQL installation password.

To explain why this is a problem, let me elaborate how Nextcloud is currently managed when using NixOS:

• In the configuration file, you enable nextcloud and provide a few settings, including the database password.
• These settings will be written to a file /var/lib/nextcloud/config/override.config.php (this takes precedence over config.php. We do this by design because NixOS is essentially a tool for configuration management and the config should be the single source of truth).
• Nextcloud unconditionally changes the database password in MySQL, the value is written to config.php, but the original password in override.config.php is still effective and thus Nextcloud now uses the wrong MySQL password which renders the instance in a broken state.

We fixed the issue ourselves now by patching out the entire behavior: https://github.com/NixOS/nixpkgs/blob/e986ddf417949e1a045430326a7238f9972827c9/pkgs/servers/nextcloud/0001-Setup-remove-custom-dbuser-creation-behavior.patch

However I figured it's still reasonable to file a bug here:

• As mentioned earlier, supplying additional *.config.php-files is useful for config management tools, however these tools are supposed to contain the single source of truth and diverging from that is IMHO a problem.
• Also, I think it's completely counter-intuitive that passwords are silently regenerated by an application that's only a consumer of the database. In the end it's the administrator's job to configure the database correctly.

It's understandable to me though if you'd prefer to keep the behavior the way it currently is for a better installation experience (even though I disagree with the motivation). In the end, we fixed the issue on our end, I thought I'd still bring it to your attention :)

Steps to reproduce

1. install Nextcloud via NixOS with mysql as db
2. during the installation the mysql pw gets changed

Expected behavior

I'd expect Nextcloud to not touch the MySQL password, reasoning is outlined in the description.

Installation method

Other Community project

Operating system

Other

PHP engine version

PHP 8.0

Web server

Nginx

Database engine version

MySQL

Is this bug present after an update or on a fresh install?

Fresh Nextcloud Server install

Are you using the Nextcloud Server Encryption module?

Encryption is Disabled

What user-backends are you using?

• [ ] Default user-backend (database)
• [ ] LDAP/ Active Directory
• [ ] SSO - SAML
• [ ] Other

Configuration report

No response

List of activated Apps

Enabled:
  - accessibility: 1.10.0
  - activity: 2.16.0
  - calendar: 3.4.3
  - circles: 24.0.1
  - cloud_federation_api: 1.7.0
  - comments: 1.14.0
  - contacts: 4.2.0
  - contactsinteraction: 1.5.0
  - cospend: 1.4.8
  - dashboard: 7.4.0
  - dav: 1.22.0
  - federatedfilesharing: 1.14.0
  - federation: 1.14.0
  - files: 1.19.0
  - files_pdfviewer: 2.5.0
  - files_rightclick: 1.3.0
  - files_sharing: 1.16.2
  - files_trashbin: 1.14.0
  - files_versions: 1.17.0
  - files_videoplayer: 1.13.0
  - firstrunwizard: 2.13.0
  - logreader: 2.9.0
  - lookup_server_connector: 1.12.0
  - maps: 0.2.1
  - nextcloud_announcements: 1.13.0
  - notifications: 2.12.1
  - oauth2: 1.12.0
  - password_policy: 1.14.0
  - photos: 1.6.0
  - privacy: 1.8.0
  - provisioning_api: 1.14.0
  - recommendations: 1.3.0
  - serverinfo: 1.14.0
  - settings: 1.6.0
  - sharebymail: 1.14.0
  - support: 1.7.0
  - survey_client: 1.12.0
  - systemtags: 1.14.0
  - text: 3.5.1
  - theming: 1.15.0
  - twofactor_backupcodes: 1.13.0
  - updatenotification: 1.14.0
  - user_saml: 5.0.2
  - user_status: 1.4.0
  - viewer: 1.8.0
  - weather_status: 1.4.0
  - workflowengine: 2.6.0
Disabled:
  - admin_audit
  - encryption
  - files_external
  - user_ldap: 1.9.0

Nextcloud Signing status

No response

Nextcloud Logs

No response

Additional info

Installed via the NixOS module of nextcloud, https://nixos.org/manual/nixos/stable/index.html#module-services-nextcloud

[kesselb]

Hi :wave:, thanks for your bug report. Would you mind to update the title? ;)

As reference https://github.com/nextcloud/server/issues/34121 which sounds similar.

[Ma27]

Hi :wave:, thanks for your bug report. Would you mind to update the title? ;)

Oof, very sorry for that, done!

As reference https://github.com/nextcloud/server/issues/34121 which sounds similar.

Now that I re-read it, it seems related indeed. However it seems to be about a slightly different case, i.e. when providing a wrong db password in the first place:

I found that after I filled in the incorrect database user/password at the first time and the script return that "MySQL username and/or password not valid.

(emphasis mine)

[CarlSchwan]

This also affect my dev environment, see https://github.com/juliushaertl/nextcloud-docker-dev/issues/77

[Sephtex]

I'm also looking why this is causign an issue since a few months and found this now. Interesting that passwords gets changed in the source of truth, which should not happen.. As I found out it is not only the dbpass, but also secret and passwordsalt. This goes all together with the fact that you can't set config_is_read_only=true anymore (https://github.com/nextcloud/server/pull/30130, probably this is just a coincidence). Unless there is something else problematic that needs to generate those secrets for which config_is_read_only=false needs to be set. Wouldn't it be better to throw errors/warning about that and not just change the passwords/secrets? I use ansible to deploy/upgrade nextcloud, and as of NC24 (alpine-3.16), I'm unable to install or upgrade to that version because of that. At the moment still searching for the best way out of the box to keep my current secrets and hopefully get to keep config_is_read_only=true

Anyway, I have config_is_read_only=true set, and by using the following lines to patch the code, I got nextcloud installed:

- name: Comment out secret generators
  ansible.builtin.replace:
    path: "{{ nextcloud_webapp_location + '/' + item.path }}"
    regexp: '^(\s*)({{ item.search }})'
    replace: '\1# \2'
  loop:
    - path: lib/private/Setup.php
      search: '[$]salt = [$]this->random->generate'
    - path: lib/private/Setup.php
      search: '[$]secret = [$]this->random->generate'
    - path: lib/private/Setup/MySQL.php
      search: '[$]this->dbPassword = str_shuffle'

What I could maybe propose is to add config parameters to disable those specific generators? (I could potentially contribute this change)

I still need to do some trickery with config_is_read_only since I rather have it always to true.

[szaimen]

Hi, please update to 24.0.9 or better 25.0.3 and report back if it fixes the issue. Thank you!

My goal is to add a label like e.g. 25-feedback to this ticket of an up-to-date major Nextcloud version where the bug could be reproduced. However this is not going to work without your help. So thanks for all your effort!

If you don't manage to reproduce the issue in time and the issue gets closed but you can reproduce the issue afterwards, feel free to create a new bug report with up-to-date information by following this link: https://github.com/nextcloud/server/issues/new?assignees=&labels=bug%2C0.+Needs+triage&template=BUG_REPORT.yml&title=%5BBug%5D%3A+

[Ma27]

Still reproducible with 25.0.3.

[szaimen]

Hopefully fixed with https://github.com/nextcloud/server/pull/36400 in 25.0.4