Nextcloud Linuxserver stuck on upgrade to 30.0.4

The Basics

  • Nextcloud Server version (e.g., 29.x.x):
    • 30.0.3 → 30.0.4
  • Operating system and version (e.g., Ubuntu 24.04):
    • Debian 11
  • PHP version (e.g, 8.3):
    • 8.3.14
  • Is this the first time you’ve seen this error? (Yes / No):
    • Yes
  • When did this problem seem to first start?
    • After upgrading to 30.0.4 from 30.0.3
  • Installation method (e.g. AlO, NCP, Bare Metal/Archive, etc.)
    • Linuxserver docker image

Summary of the issue you are facing:

I’ve tried updating the container to 30.0.4. The update seems to be fine, but the webUI is stuck on a page saying that an upgrade is required. I’ve tried manualy running occ upgrade , it doesn’t fail, but it doesn’t fix anything.

Log entries

Configuration

Nextcloud

{
    "system": {
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
            "192.168.1.43:9610",
            "cloud.billos.fr"
        ],
        "dbtype": "pgsql",
        "version": "30.0.3.2",
        "overwrite.cli.url": "https:\/\/cloud.billos.fr",
        "overwriteprotocol": "https",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbport": "",
        "dbtableprefix": "oc_",
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "installed": true,
        "memcache.local": "\\OC\\Memcache\\APCu",
        "filelocking.enabled": true,
        "memcache.locking": "\\OC\\Memcache\\Redis",
        "memcache.distributed": "\\OC\\Memcache\\Redis",
        "allow_local_remote_servers": true,
        "debug": false,
        "app_install_overwrite": [
            "gluusso"
        ],
        "upgrade.disable-web": true,
        "maintenance": false,
        "maintenance_window_start": 1,
        "mail_from_address": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpmode": "smtp",
        "mail_sendmailmode": "smtp",
        "mail_domain": "***REMOVED SENSITIVE VALUE***",
        "mail_smtphost": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpport": "587",
        "mail_smtpauth": 1,
        "mail_smtpname": "***REMOVED SENSITIVE VALUE***",
        "mail_smtppassword": "***REMOVED SENSITIVE VALUE***",
        "loglevel": 2,
        "default_phone_region": "FR",
        "redis": {
            "host": "***REMOVED SENSITIVE VALUE***",
            "port": 6379,
            "timeout": "1.5"
        }
    }
}

Apps

Enabled:
  - cloud_federation_api: 1.13.0
  - dav: 1.31.1
  - federatedfilesharing: 1.20.0
  - files: 2.2.0
  - lookup_server_connector: 1.18.0
  - oauth2: 1.18.1
  - provisioning_api: 1.20.0
  - settings: 1.13.0
  - theming: 2.5.0
  - twofactor_backupcodes: 1.19.0
  - viewer: 3.0.0
  - workflowengine: 2.12.0
Disabled:
  - activity: 3.0.0 (installed 3.0.0)
  - admin_audit: 1.20.0
  - app_api: 4.0.3 (installed 4.0.3)
  - bruteforcesettings: 3.0.0 (installed 3.0.0)
  - calendar: 5.0.6 (installed 5.0.6)
  - circles: 30.0.0 (installed 30.0.0)
  - comments: 1.20.1 (installed 1.20.1)
  - contacts: 6.1.1 (installed 6.1.1)
  - contactsinteraction: 1.11.0 (installed 1.11.0)
  - cospend: 2.0.0 (installed 2.0.0)
  - dashboard: 7.10.0 (installed 7.10.0)
  - encryption: 2.18.0
  - federation: 1.20.0 (installed 1.20.0)
  - files_downloadlimit: 3.0.0 (installed 3.0.0)
  - files_external: 1.22.0 (installed 1.22.0)
  - files_pdfviewer: 3.0.0 (installed 3.0.0)
  - files_reminders: 1.3.0 (installed 1.3.0)
  - files_sharing: 1.22.0 (installed 1.22.0)
  - files_trashbin: 1.20.1 (installed 1.20.1)
  - files_versions: 1.23.0 (installed 1.23.0)
  - firstrunwizard: 3.0.0 (installed 3.0.0)
  - integration_forgejo: 1.0.18 (installed 1.0.18)
  - integration_homeassistant: 0.0.5 (installed 0.0.5)
  - logreader: 3.0.0 (installed 3.0.0)
  - nextcloud_announcements: 2.0.0 (installed 1.17.0)
  - notes: 4.11.0 (installed 4.11.0)
  - notifications: 3.0.0 (installed 3.0.0)
  - oidc: 1.1.0 (installed 1.1.0)
  - oidc_login: 3.2.0 (installed 3.2.0)
  - onlyoffice: 9.5.0 (installed 9.5.0)
  - password_policy: 2.0.0 (installed 2.0.0)
  - photos: 3.0.2 (installed 3.0.2)
  - privacy: 2.0.0 (installed 2.0.0)
  - recommendations: 3.0.0 (installed 3.0.0)
  - related_resources: 1.5.0 (installed 1.5.0)
  - richdocuments: 8.5.3 (installed 8.5.3)
  - serverinfo: 2.0.0 (installed 2.0.0)
  - sharebymail: 1.20.0 (installed 1.20.0)
  - side_menu: 4.0.1 (installed 4.0.1)
  - support: 2.0.0 (installed 2.0.0)
  - survey_client: 2.0.0 (installed 2.0.0)
  - suspicious_login: 8.0.0
  - systemtags: 1.20.0 (installed 1.20.0)
  - tasks: 0.16.1 (installed 0.16.1)
  - text: 4.1.0 (installed 4.1.0)
  - twofactor_nextcloud_notification: 4.0.0
  - twofactor_totp: 12.0.0-dev
  - updatenotification: 1.20.0 (installed 1.20.0)
  - user_ldap: 1.21.0
  - user_oidc: 6.1.2 (installed 6.1.2)
  - user_status: 1.10.0 (installed 1.10.0)
  - weather_status: 1.10.0 (installed 1.10.0)
  - webhook_listeners: 1.1.0-dev (installed 1.1.0-dev)

Same problem (I am upgrading from 30.0.2).

Your log indicates a finished upgrade and the version bump in the log output means you’re running the new version already.

However your configuration does not reflect that. Did you generate that config via occ config:list system after the upgrade or is it from before?

How precisely did you trigger the container upgrade?

And can you post your Compose file?

I’ve run the occ config list after the upgrade.

My compose is as follow :

Again, how precisely did you upgrade the container?

Also, please check your Nextcloud container startup logs.

It looks like server itself is already upgraded.

Any chance you’re trying to update Nextcloud without upgrading the image?

I’ve tried multiple times
occ upgrade and occ maintenance:repair

What do you mean updating without upgrading the image ?
The version is set in the compose file

If you are running these commands manually in an image based deployment something is already wrong. These are handled by the entrypoint/etc in the image.

The container log (ideally of the original update attempt) is what would probably be useful here.

In the LSIO image, there are other relevant bits not handled by server that deal with upgrading shipped apps/etc. For example, see here.

A wild guess is a permissions problem somewhere within /config.

What do you mean updating without upgrading the image ?

A bit back LSIO had a different upgrade process. Some people still attempt to use it.

The version is set in the compose file

Yes, these days. So you’re basically bumping the version in Compose then doing docker compose pull && docker compose up -d to trigger a container update, correct?

Yes that’s what I did before occ upgrade and repair

You said you don’t get any errors when you manually run occ upgrade? Do you get any output?

Are you sure you don’t have a second instance or something?

I ask because you said your posted config is from after the upgrade, but when you go to https://cloud.billos.fr/status.php the correct version is shown, but the indication is that you still need to run your db upgrades (which is running occ upgrade does).

Another random possibility: do you perhaps have a backup config file located in your config/? Anything in that folder with a *.config.php gets merged to make your real config. That might explain why your version string doesn’t match what’s actually installed.

1 Like

Oh that was it !
I had a previous old.config.php file before trying redis

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.