[Bug]: Large files (Office documents, DWG) get locked/corrupted after upgrade to 34.x — regression suspected in propagator lock handling

[LeoPriet0]

⚠️ This issue respects the following points: ⚠️

• This is a bug, not a question or a configuration/webserver/proxy issue.
• This issue is not already reported on Github OR Nextcloud Community Forum (I've searched it).
• Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
• I agree to follow Nextcloud's Code of Conduct.

Bug description

Large files (Office documents such as Excel/PowerPoint, and AutoCAD .dwg) get locked or corrupted shortly after being saved to a Nextcloud-synced folder, when accessed via the desktop client with VFS (on-demand files) enabled.

• Excel: file saves successfully, but Excel cannot reopen it immediately after — "sharing violation" error.
• PowerPoint: fails to save, and in some cases embedded images in the saved file become corrupted.
• AutoCAD (.dwg): same class of symptom — file becomes inaccessible/locked shortly after save.

Server logs show repeated LockedException and Sabre\DAV\Exception\Locked errors on the affected files at the time of the incidents.

This started roughly 1.5 months ago, coinciding with an upgrade from the 33.x line to 34.0.x (Hub 26 Spring, released June 9, 2026). We had not seen this behavior before that upgrade.

We noticed the following changelog entry for 34.0.0 that touches directly on this area:
"Fix(propagator): Improve lock behavior of propagator"
We suspect this change (or a related one in the same release) may have introduced a regression in how locks are held/released during sync of large files.

Ruled out:

• ONLYOFFICE: initially suspected, since logs also showed unrelated onlyoffice ConnectException/timeout entries (preview/thumbnail generation for large .xlsx files timing out at 120s). We disabled the ONLYOFFICE app entirely as a test. The Excel/PowerPoint locking issue persisted after disabling it, so ONLYOFFICE is not the root cause of this specific bug (though the preview-generation timeout appears to be a separate, real issue worth noting).
• Missing Redis/memcache for locking: confirmed already configured (no admin warning shown), so this is not a case of transactional locking falling back to the database.

Pattern:

• Only affects large files (exact size threshold not yet pinned down, but small files are unaffected)
• Affects multiple unrelated file formats (Office documents and AutoCAD .dwg), suggesting the cause is in generic file-locking/sync logic, not format-specific handling
• Reproduced independently across several separate Nextcloud deployments we manage, all recently upgraded to 34.x

Environment:

• Nextcloud Server: Hub 26 Spring (34.0.2)
• Desktop client: 34.0.1 (also reproduced on earlier 33.x client versions)
• OS of affected clients: Windows
• VFS (on-demand files / Virtual Files Support): enabled
• memcache.local and memcache.locking: configured (Redis in use)

Steps to reproduce

1. Open a large file (Excel, PowerPoint, or AutoCAD .dwg) from a Nextcloud-synced folder via the desktop client, with VFS/on-demand files enabled
2. Edit the file and save
3. Attempt to reopen the file (Excel/PowerPoint) or continue editing it (AutoCAD)

Expected behavior

The file should save and be immediately reopenable/editable, exactly as it behaved before upgrading to Nextcloud 34.x. No lock exceptions should appear in the server logs for normal single-user edit/save cycles.

Nextcloud Server version

34

Operating system

Other

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

List of activated Apps

Nextcloud Signing status

Nextcloud Logs

Additional info

No response