chore: bump Nextcloud to 34.0.3; 33.0.8:3 → 34.0.3:0

[helix-nine]

Bumps the bundled Nextcloud image from 33.0.8 to 34.0.3, releasing as StartOS version 34.0.3:0, and hardens the two recovery paths that a major upgrade drives traffic to.

The 33 line has not moved since 33.0.8 (33.0.8 is the newest 33.x.y-apache tag on Docker Hub), so 34.0.3 is the only upstream release available. This is a major bump, 33 → 34.

The 32.x cohort

An install still on 32.0.11:0 is offered this update, and it cannot succeed. Measured, not inferred:

• 32.0.11:0 is still in otherVersions on both the beta and production registries, and is in other[] at startos/versions/index.ts:8 for exactly that reason. It is where a StartOS 0.3.5.x carry-over lands.
• Executing the real VersionGraph from the installed SDK against this branch: canMigrateFrom is >=32.0.11:0 && <=34.0.3:0, and 32.0.11:0 satisfies it. StartOS accepts the hop and the Updates page offers it.
• $OC_VersionCanBeUpgradedFrom in v34.0.3/version.php is {33.0, 34.0}. Nextcloud genuinely refuses 32 → 34.
• startos/init/bootstrapNextcloud.ts:165 therefore throws: image[0] is 34, installed[0] + 1 is 33.

The user downloads the update, StartOS snapshots the volumes, init fails, and the whole thing rolls back. Data is safe — the guard is doing its job.

The remedy is a two-step update, and it exists in the product today. The Marketplace listing renders a version picker over best + otherVersions (shared-libs/ts-modules/marketplace/src/components/preview.component.ts versions$ → about.component.ts → MarketplaceVersionsComponent), and MarketplaceControlsComponent renders Update for whichever version is selected once it is newer than the installed one. 33.0.8:3 stays indexed — it is the newest :N of its (flavor, upstream) group, so pruning never touches it. So a 32.x user picks 33.0.8:3 from the version list, updates, and then updates again to 34.0.3:0.

Nothing pointed them there, so this branch does:

• the guard message now names the two-step path instead of only naming the problem;
• the release notes lead with it, in all five locales.

Why the version graph is left alone

Raising the floor is possible — a 33.0.5:0 anchor with up: IMPOSSIBLE (33.0.5:0 being the oldest 33.x release) yields >=33.0.5:0 && <=34.0.3:0, with every 33.x revision still reachable and v33.0.8_2's migrateFrom035x still running for all of them. Verified by executing the graph. Dropping v_32_0_11_0 on its own does the opposite, widening the range to <=34.0.3:0, because the floor is set by the lowest vertex whose up is IMPOSSIBLE.

It would be the right change if the registry published canMigrateFrom. It does not: PackageVersionInfo::from_s9pk sets source_version: None, // TODO (shared-libs/crates/start-core/src/registry/package/index.rs:155), and the live production response for this package confirms it — "sourceVersion": null. That leaves inert both the registry's own source_version filter (registry/package/get.rs:180) and updates-refinement.service.ts, the UI machinery built to refetch a reachable version when best is not one. So the 32.x user would still be offered 34.0.3:0, and the failure would move from this package's clear domain message to service_map.rs's unsatisfiable target_range(prev_can_migrate_to ∧ next_can_migrate_from) → uninit target range … is unsatisfiable — no version can satisfy it (host contract violation).

A worse message for the same outcome. Revisit once the registry publishes sourceVersion — at that point the floor makes StartOS route the 32.x cohort to 33.0.8:3 by itself.

Why 34 is worth taking now

Five earlier 34.x PRs (#110, #111, #112, #113, #114, #123) were closed. Two things named in #123 as reasons to wait have since resolved:

• 34.0.2 shipped with ImageMagick previews disabled. lib/private/Preview/IMagickSupport.php at v34.0.3 is byte-identical to v33.0.8 — PDF, SVG, TIFF, HEIC and PSD previews are back, via the magic-byte-checking re-enable (server#62620).
• A 33.x stepping stone had not shipped. 33.0.8:3 is now the registry's best, so the ordinary cohort is one major below 34.

The bump

• nextcloud.Dockerfile — NEXTCLOUD_VERSION 33.0.8 → 34.0.3, per UPDATING.md. The upstream nextcloud/docker 33→34 apache Dockerfile diff is only php:8.4-apache-trixie → php:8.5-apache-trixie plus the version and tarball-URL lines; same Debian trixie base, so the ffmpeg layer and the a2enconf startos-proxy-keepalive layer are unaffected, and entrypoint.sh is byte-identical. nextcloud:34.0.3-apache resolves on Docker Hub for amd64 and arm64 (pushed 2026-08-17).
• startos/actions/maintenance/disableUnstableApps.ts — adds appstore, files_lock and office. That is exactly core/shipped.json's defaultEnabled delta between v33.0.8 and v34.0.3 (nothing removed). appstore is load-bearing: 34 also adds it to alwaysEnabled, and AppManager::disableApp throws on an always-enabled app so Disable.php sets exitCode = 2.
• startos/versions/current.ts — version and release notes, five locales.
• UPDATING.md — the Nextcloud section documented only a patch bump. It now records the four checks a major needs.
• package-lock.json — refreshes the filebrowser-startos#next pin (c35ff45 → ed12408). One line; package.json unchanged.

@start9labs/start-sdk is already at 2.0.9 (npm latest), so there is no SDK bump.

Every occ command the package invokes was diffed between v33.0.8 and v34.0.3: only #[\Override] attributes, declare(strict_types=1), and an unrelated new --no-password option on user:resetpassword. occ status still emits installed and needsDbUpgrade; core/register_command.php gains two background-job commands and removes none. Every key startos/fileModels/config.php.ts models is still in v34.0.3's config.sample.php — the key-set diff is additions only, plus a removal of mount_file, which the package does not model.

The hardening

Both are pre-existing, and both are worst exactly on the instances this release sends to them.

Disable Non-default Apps no longer aborts on the first failure (closes #127). It fanned every occ app:disable out under Promise.all + execFail, so one non-zero exit rejected the lot and withTemp's finally { destroy() } tore the subcontainer down under the still-running siblings — and the disabledApps report was never returned, leaving a bare ExitError. occ app:disable runs the app's own uninstall repair steps, so a fataling app is simultaneously the likeliest one to fail and the reason the action was run at all. Disables now run one at a time through exec, and the result reports what was disabled and, separately, what was not.

Reading the enabled-app list moved into readEnabledApps in utils.ts, which slices from the first { (a PHP startup or deprecation notice on stdout ahead of occ's JSON otherwise gives SyntaxError: Unexpected token 'P') and tolerates a missing enabled key instead of Object.keys(undefined).

Note the concurrency hazard here is the timeout and the teardown, not lost writes: AppManager::disableApp writes enablement to oc_appconfig in Postgres, not to config.php.

talk-turn now checks that Talk is enabled, not merely present (closes #128). It decided Talk was usable from the presence of custom_apps/spreed. OC\Console\Application::loadCommands iterates getEnabledApps(), and Updater::checkAppsRequirements calls disableApp($app, true) on every app without a release for the new major while leaving its files in place — so after a major upgrade the check passed while talk:turn:add did not exist. allOk stayed false, talkTurnConfigured was never recorded, and the relay silently stopped being applied while every chain build retried. Of the 457 apps with a Nextcloud 33 release, 63 have no 34 release.

hasNextcloudApp keeps its presence semantics for the three App Commands prechecks: those are allowedStatuses: 'any', so they must work with Postgres down, and their failure mode is an explicit failed-task notification rather than a silent retry.

Version file

current.ts is edited in place. 33.0.8:3 carries up: async () => {}, so there is no migration to strand and no reason to spin it into other[]. Confirmed by executing the graph before and after: v33.0.8_2.ts's clearTask + migrateFrom035x still runs for 32.0.11:0, 33.0.5:0, 33.0.7:0, 33.0.8:0 and 33.0.8:1, and is still correctly skipped for :2 and :3. 34.0.3:0 is unpublished (registry best is 33.0.8:3).

Release notes

They describe Nextcloud 34's feature set, not the 34.0.1–34.0.3 point fixes — every fix in those point releases was backported to the 33 line as well, so a user arriving from 33.0.8:3 already has them. Verified pairwise against the upstream release bodies:

fix	34.x	also in
encrypted→unencrypted object-storage corruption	server#63020 (34.0.3)	server#63019 (33.0.8)
admin permission for all systemtag updates	server#62924 (34.0.3)	server#62923 (33.0.8)
preview file-signature check	server#62620 (34.0.3)	server#62619 (33.0.8)
ffprobe hangs	server#61182 (34.0.1)	server#61183 (33.0.6)
rate limiting for federated shares	server#62130 (34.0.2)	server#62129 (33.0.7)

The recovery-path bullet names the Disable Non-default Apps action, and each locale quotes that action's own dictionary entry verbatim (startos/i18n/dictionaries/translations.ts key 28) rather than a fresh translation.

Issues filed while reviewing, and their outcome

• Disable Non-default Apps runs every occ app:disable concurrently; one failure aborts the rest #127 — fixed here.
• hasNextcloudApp passes for an app a major upgrade disabled but left on disk #128 — fixed here.
• Restore has no one-major-at-a-time guard, and unlike an update it cannot roll back #129 (restore has no one-major guard) — closed, premise does not hold. A backup carries the installed s9pk (service/mod.rs:810) and restore installs from that exact file (backup/restore.rs:219-225), so the restored code and the restored database always agree. The recover dialog also refuses a package that is already installed. There is no path by which a 32.x backup lands on a package shipping Nextcloud 34.
• External Storage's filebrowser versionRange cannot follow the dependency to its #quantum flavor #130 (File Browser versionRange cannot follow the #quantum flavor) — closed, already handled. filebrowser-quantum-startos declares .satisfies('2.63.23:0') for exactly this, and StartOS checks a dependency's aliases as well as its version (dep-error.service.ts:129-130). ^2.62.2:1 is satisfied by 2.63.23:0, so the dependency resolves after a flavor switch. Quantum also chowns its data volume to 1000:1000, which is what the idmap mount in main.ts requires.

Left as-is

• The preserved-defaults list is still a hand-maintained mirror of core/shipped.json. Across v32.0.11, v33.0.8 and v34.0.3 the 58-entry literal is exactly shippedApps ∪ {calendar, contacts} with no drift, and occ app:list --shipped=true --output=json would collapse it to one exec. Worth doing, but not under a major bump — getting it wrong fails silently on the recovery action itself.
• files_lock is now preserved, and it is also an app-store app on 33. A user who installed it from the store carries a 33-era copy; after this upgrade it is exactly the kind of app that can break the UI, and the recovery action will now skip it. Excluding it would instead disable an app Nextcloud 34 ships enabled by default.

Not verified

No make, no s9pk pack, no VM install, and specifically no 33 → 34 upgrade exercised end to end. This crosses a major and runs a database schema change; it wants a real upgrade run before it goes out. npm run check and npx prettier --check are green.

Full upstream changelogs: 34.0.0 · 34.0.1 · 34.0.2 · 34.0.3

Merge with a merge commit — do not squash. next is long-lived: a merge commit leaves it a true ancestor of master, so it fast-forwards cleanly afterwards.