[Bug]: CLI installer doesn't generate instanceid when --disable-admin-user is used

[Elemecca]

⚠️ This issue respects the following points: ⚠️

• This is a bug, not a question or a configuration/webserver/proxy issue.
• This issue is not already reported on Github OR Nextcloud Community Forum (I've searched it).
• Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
• I agree to follow Nextcloud's Code of Conduct.

Bug description

In NextCloud 32 (but not 33), when installing using occ maintenance:install, if --disable-admin-user is passed, the installer does not set instanceid when it generates config/config.php.

Normally that will be fixed the first time the instanceid is needed when serving an HTTP request, but if config_is_read_only is enabled before the first request is received (which is reasonable to expect as part of a fully-automated installation) it causes all requests to return 500 errors.

Steps to reproduce

1. Download and unpack NextCloud 32.0.8
2. Call occ maintenance:install and pass --disable-admin-user
3. Immediately, before making any HTTP requests, make the config read-only:
   1. Set 'config_is_read_only' => true in config/config.php
   2. chmod 0440 config/config.php
4. Attempt to visit the freshly-installed site in a browser.

The site always returns a 500 error with the message

Config is set to be read-only via option "config_is_read_only".
Unset "config_is_read_only" to allow changes to the config file.

The error happens because the instanceid is not set, so NextCloud tries to set it, which fails because the config is read-only.

Expected behavior

The installer should set instanceid regardless of what options are passed.

It should be possible to script installation of NextCloud with occ maintenance:install and immediately make the config read-only without having to first visit the installation in a browser.

Nextcloud Server version

32

Operating system

Debian/Ubuntu

PHP engine version

PHP 8.4

Web server

Nginx

Database engine version

MariaDB

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

{
    "system": {
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
            "localhost"
        ],
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "dbtype": "mysql",
        "version": "32.0.8.2",
        "overwrite.cli.url": "http:\/\/localhost",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbtableprefix": "oc_",
        "mysql.utf8mb4": true,
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "installed": true,
        "config_is_read_only": true
    }
}

List of activated Apps

Enabled:
  - activity: 5.0.0
  - app_api: 32.0.0
  - bruteforcesettings: 5.0.0
  - circles: 32.0.0
  - cloud_federation_api: 1.16.0
  - comments: 1.22.0
  - contactsinteraction: 1.13.1
  - dashboard: 7.12.0
  - dav: 1.34.2
  - federatedfilesharing: 1.22.0
  - federation: 1.22.0
  - files: 2.4.0
  - files_downloadlimit: 5.0.0
  - files_pdfviewer: 5.0.0
  - files_reminders: 1.5.0
  - files_sharing: 1.24.1
  - files_trashbin: 1.22.0
  - files_versions: 1.25.0
  - firstrunwizard: 5.0.0
  - logreader: 5.0.0
  - lookup_server_connector: 1.20.0
  - nextcloud_announcements: 4.0.0
  - notifications: 5.0.0
  - oauth2: 1.20.0
  - password_policy: 4.0.0
  - photos: 5.0.0
  - privacy: 4.0.0
  - profile: 1.1.0
  - provisioning_api: 1.22.0
  - recommendations: 5.0.0
  - related_resources: 3.0.0
  - serverinfo: 4.0.0
  - settings: 1.15.1
  - sharebymail: 1.22.0
  - support: 4.0.0
  - survey_client: 4.0.0
  - systemtags: 1.22.0
  - text: 6.0.1
  - theming: 2.7.0
  - twofactor_backupcodes: 1.21.0
  - updatenotification: 1.22.0
  - user_status: 1.12.0
  - viewer: 5.0.0
  - weather_status: 1.12.0
  - webhook_listeners: 1.3.0
  - workflowengine: 2.14.0
Disabled:
  - admin_audit: 1.22.0
  - encryption: 2.20.0
  - files_external: 1.24.1
  - suspicious_login: 10.0.0
  - twofactor_nextcloud_notification: 6.0.0
  - twofactor_totp: 14.0.0
  - user_ldap: 1.23.0

Nextcloud Signing status

Nextcloud Logs

Additional info

Looking through the source code, it appears that the only location where instanceid is set is OC_Util::getInstanceId(). That method is not called in OC\Setup::install(), so the installer is depending on something it calls happening to transitively call getInstanceId() in order to generate the instanceid.

I'm seeing this issue in 32.0.8 (the most recent 32.x release) but it seems to have been fixed in or before version 33.0.2 (the most recent 33.x release). However, looking at the code on master (fdfcc00), OC\Setup::install() still doesn't directly set instanceid or call OC_Util::getInstanceId() to cause it to be set, so I think it was only fixed by chance and could easily break again.

In my opinion this should be fixed either by moving the code that generates instanceid from OC_Util::getInstanceId() to OC\Setup::install() (since it should only need to be generated during installation), or by adding an explicit call of OC_Util::getInstanceId() in OC\Setup::install() with a comment explaining that it generates instanceid.

This issue was brought up once on the forum. That user fixed their setup by making an HTTP request to the site with curl. While that is a viable workaround, in my opinion the bug should be fixed properly.

I'm working around this issue by making my script generate its own instanceid and create config/config.php with only that setting before calling occ maintenance:install.