Sequential NS7-migrated Nextcloud upgrades can leave config.php behind version.php

[DavidePrincipi]

Steps to reproduce

• Migrate a NethServer 7 instance to NS8 with an old Nextcloud install
• Update sequentially through several major Nextcloud versions in a row (e.g. 29 → 30 → 31 → 32 → 33), one update-module run per version, with no overlap (logs show each run completing before the next starts)
• Check the instance state after the last update

Expected behavior

Each intermediate upgrade step fully completes (including the occ upgrade performed by the container entrypoint) before the module is restarted with the next target image, so config.php's version always matches version.php at the end of every step, and the instance ends up fully upgraded and out of maintenance mode.

Actual behavior

The instance was left in an inconsistent state: version.php reported 33 while config.php still reported 31. No occ action was possible and Nextcloud was stuck in maintenance mode.

Components

ns8-nextcloud 1.7.4

See also

• NethServer/ns8-nextcloud@8744c76
• https://mattermost.nethesis.it/nethesis/pl/zf5z4roicfbgxxe1wr9reesngr
• Nextcloud upgrade from 1.6.1 may leave the instance in maintenance mode #8050

[DavidePrincipi]

Possible bug cause

The wait-startup script loop may be slower than we expect (occ status && sleep 1s x 60 times), since "occ status" execution is not immediate. After 90 seconds Systemd kills the nextcloud-app container.

When that happens, the upgrade gets forcibly interrupted partway through and restarted from scratch, leaving the software's internal version number out of sync with its actual configuration.

The update process then keeps going to the next version anyway, unaware anything went wrong, until Nextcloud itself refuses to continue because too many versions were skipped at once — leaving the system stuck partway upgraded and unusable.