Preview generation silently fails when previews are missing after restore

⚠️ This issue respects the following points: ⚠️

• This is not a troubleshooting question, general support matter, or webserver/proxy problem, but likely a bug (if unsure, ask the Community Help Forum).
• This issue is not already reported on Github OR solved at the Community Help Forum (I've searched!).
• I'm using a maintained major version of Nextcloud Server and tested against the latest patch level. (Supported major versions and current patch levels).
• I agree to follow Nextcloud's Code of Conduct.
• I've tried my best to provide clear reproduction steps that someone unfamiliar with this bug could use to reproduce it.

Bug description

After rebuilding the server and restoring from a Nextcloud AIO backup that excluded the preview folder, no new previews are generated for any file. Previews that existed on disk before the restore are still served correctly. Files without a preview never get one.

The preview endpoint returns an empty JSON array instead of an image, and nothing is written to the log even at loglevel 0.

Steps to reproduce

1. Restore from an AIO backup with previews excluded
2. Request a preview for a file that has no preview on disk:
3. GET /index.php/core/preview?fileId=&x=256&y=256&a=1
4. Response is []
5. Request a preview for a file that does have previews on disk — an image is returned normally

Expected behavior

A preview is generated and returned for files that don't yet have one.

Actual behaviour

[] is returned, no preview file is created, no log entry is produced.

Nextcloud Server version

33

Operating system

Debian/Ubuntu

PHP engine version

None

Web server

None

Database engine version

None

Is this bug present after an update or on a fresh install?

None

Are you using the Nextcloud Server Encryption module?

None

What user-backends are you using?

• Default user-backend (database)
• LDAP/ Active Directory
• SSO - SAML
• Other

Configuration report

Server configuration
Nextcloud: 33.0.8.2
Install method: AIO (nextcloud-aio-nextcloud, Apache, PostgreSQL, Redis, Imaginary all healthy)
previewgenerator: 5.14.0 (problem reproduces independently of this app)
OS: Ubuntu, Docker, btrfs single drive
PHP memory_limit: 512M
preview_max_filesize_image and preview_max_memory: unset (defaults)

List of activated Apps

Nextcloud Signing status

Nextcloud Logs

Logs

Nothing is emitted in nextcloud.log or container stdout at loglevel 0 during a failing preview request or during preview:generate-all.

Imaginary access log during a Nextcloud-initiated run shows repeated 400 responses (85–91 byte bodies) and occasional 422, with VIPS-WARNING: source: bad seek to <offset>.

Additional info

What has been ruled out

• Not the provider layer. Reproduces with enabledPreviewProviders reduced to OC\Preview\JPEG and OC\Preview\PNG only.
• Not Imaginary. Posting the exact pipeline Nextcloud sends (convert→fit, png, 2048×2048, stripmeta, norotation, quality 60) to nextcloud-aio-imaginary:9000 via curl with the correct key returns HTTP 200 and valid image data for the same HEIC and JPEG source files. The same requests from Nextcloud return 400.
• Not permissions. Source files and appdata are owned by and readable/writable as www-data; touch and mkdir in the preview directory succeed.
• Not disk or filesystem. btrfs, 935 GB free, metadata 2.03/4.00 GiB used.
• Not the appdata cache. occ files:scan-app-data completes and counts 226,602 previews.
• Not enable_previews. Set to true.
• Not cron/background jobs. backgroundjobs_mode is cron and the process is running.
• Redis and the nextcloud container were restarted; no change.

occ preview:generate-all prints Generating previews for for every file and completes a full library scan in ~12 minutes without writing anything.

Start with the /index.php/core/preview endpoint and the occ preview:generate-all command, reproducing the difference between files with existing previews and files without them. Trace the JPEG and PNG provider path under the reduced enabledPreviewProviders configuration and compare the failing Imaginary requests with the successful curl request. Done means missing previews are generated and returned, with failures producing useful log output.