Yes, I configured Collabora with the FQDN “collabora.canducci-adv.it” (a record in stored in the public DNS - it responds to pings). The collabora container is on the same server and appears to be accessible from NextCloud, as files stored in NC, such as .doc or .xls, are opened regularly. The FQDN hasn’t changed since it was stored before the backup. I use Encrypt’s certificate, and from the NS8 Web GUI, it appears to be active.
IIUC, you’re restoring a separate Nextcloud instance alongside the production one on the same node. I’m not sure whether this scenario is supported or will work reliably.
I think it should work. First, if I remember correctly, we can connect multiple Nextcloud instances to the same Collabora instance. Also, during the restore, we normally shouldn’t run into any port conflicts on the Nextcloud side—so it should work.
I can try to reproduce the issue since I’m currently working on the upgrade to Nextcloud 33.
By the way, @davidep: I upgraded on my server and the heavy cron load is not happening.
The wait-startup script was not waiting long enough for Nextcloud to be fully ready before returning control to the system.
It relied on the command occ status --output json and only checked whether the installed field was set to true. However, Nextcloud can be marked as installed while still being in maintenance mode (for example, during database schema migrations). As a result:
The script exited prematurely, assuming Nextcloud was ready
The systemd service (50systemd) returned immediately
The next script (80configure_collabora) started before the database had fully completed its initialization
This caused the Collabora configuration to fail
From the logs, 80configure_collabora started at 16:51:43, while the database only finished initializing at 16:52:02 — 19 seconds later. That’s clearly too early.
PROPOSED SOLUTION:
Replace the check with the command occ status -e, which returns a meaningful exit code:
Exit code 0: Nextcloud is fully operational (installed + not in maintenance mode + database migrations completed)
Exit code 1: Maintenance mode is enabled
Exit code 2: Database upgrade required
This approach ensures the script waits until all three conditions are met before proceeding, instead of relying solely on the installed flag. It removes ambiguity and guarantees that subsequent services only start when Nextcloud is truly ready.
Another option is to keep using occ status --output json, but validate all relevant fields instead of just one:
ret, out = occ([“status”, “–output”, “json”])
status = json.loads(out)
if status[“installed”] and not status[“maintenance”] and not status[“needsDbUpgrade”]:
break
print(
f"wait-startup: waiting for nextcloud-app ({i}): "
f"installed={status.get(‘installed’)}, "
f"maintenance={status.get(‘maintenance’)}, "
f"needsDbUpgrade={status.get(‘needsDbUpgrade’)}",
file=sys.stderr
)
This approach:
Retrieves the full status in JSON format instead of relying on a simple exit code
Explicitly checks three conditions:
installed: true — Nextcloud is installed
maintenance: false — Not in maintenance mode
needsDbUpgrade: false — No pending database migrations
Logs the actual values, which helps with troubleshooting: wait-startup: waiting for nextcloud-app (3): installed=true, maintenance=true, needsDbUpgrade=false wait-startup: waiting for nextcloud-app (7): installed=true, maintenance=false, needsDbUpgrade=false
Pros: More verbose and detailed, making debugging easier
Cons: Requires JSON parsing, which is heavier than relying on a simple exit code