[Bug]: 32.0.6.1 (client 3.17.4) Server fails to catch up after a burst of file writes

[Bockeman]

⚠️ 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

After a burst of file writes, the server fails to catch up.

A snippet from the log file shows

  2026-03-20 14:37:54 [E] 1726: Server did not catch up after 00:12:18
  /extra/reference/nextcloud/bobw/files/Experiment
  -rw-r--r-- 1 bobw warren 1083 2026-03-20 14:25:36 nextcloud_stress_000.txt
  -rw-r--r-- 1 bobw warren 1084 2026-03-20 14:25:36 nextcloud_stress_001.txt
  /extra/davfs/nextcloud/bobw/files/Experiment
  -rw-r--r-- 1 bobw warren  898 2026-03-20 14:23:14 nextcloud_stress_000.txt
  -rw-r--r-- 1 bobw warren 1084 2026-03-20 14:25:36 nextcloud_stress_001.txt

where it is evident that after 12 minutes,
the version of nextcloud_stress_000.txt with size 898 on the server (extracted via davfs)
has not caught up with the same named file of size 1083 on the client (reference).

Steps to reproduce

1. Set up a Nextcloud Server (which emulates a remote connection with ~150ms delay)
2. Set up a Nextcloud Client and Add Folder Sync Connection to folder "Experiment" (not virtual)
3. Run a script which generates a burst of file writes on one client
4. then loops waiting for the server and other clients to catch up
5. Observe the upload to the server where the signature of the file shows it has not caught up

Standalone nextcloud environment for demonstrating issues.

Expected behavior

No differences between files on client and files on server
after allowing sufficient time for the Nextcloud server to catch up.

Nextcloud Server version

32

Operating system

Other

PHP engine version

PHP 8.4

Web server

Apache (supported)

Database engine version

MariaDB

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:
sudo -u apache php -f /usr/share/nextcloud/console.php config:list system | grep version\.:
  "version": "32.0.6.1",

Client:
nextcloud --version
  Nextcloud version 3.17.4daily
  Git revision 371e4b9311e851dbb8d6ae6f7c3f77af958e1a33
  Using Qt 6.10.1, built against Qt 6.10.1
  Using Qt platform plugin 'xcb'
  Using 'OpenSSL 3.5.4 30 Sep 2025'
  Running on Fedora Linux 43 (Forty Three), x86_64

php -v
PHP 8.4.18 (cli) (built: Feb 10 2026 17:48:03) (NTS gcc x86_64)
Copyright (c) The PHP Group
Built by Fedora Project
Zend Engine v4.4.18, Copyright (c) Zend Technologies
    with Zend OPcache v8.4.18, Copyright (c), by Zend Technologies

https://localhost/nextcloud/index.php/settings/integrity/failed
  None relevant

List of activated Apps

Not relevant

Nextcloud Signing status

None relevant

Nextcloud Logs

I don't think these very large log files are helpful
ls -lh /extra/server/nextcloud/nextcloud.log*
-rw-r----- 1 apache apache  53M 2026-03-20 15:40 /extra/server/nextcloud/nextcloud.log
-rw-r----- 1 apache apache 101M 2026-03-11 12:55 /extra/server/nextcloud/nextcloud.log.1
tail -5 /extra/server/nextcloud/nextcloud.log
{"reqId":"ab1qCEPiiDx0lHbQtTe0KQAAAAQ","level":1,"time":"March 20, 2026 15:38:49","remoteAddr":"127.0.0.1","user":"bobw","app":"no app in context","method":"GET","url":"/nextcloud/ocs/v1.php/cloud/user?format=json","scriptName":"/nextcloud/ocs/v1.php","message":"The user config key files/quota is not defined in the config lexicon","userAgent":"Mozilla/5.0 (Linux) mirall/3.17.4daily (Nextcloud, fedora-6.19.7-200.fc43.x86_64 ClientArchitecture: x86_64 OsArchitecture: x86_64)","version":"32.0.6.1","clientReqId":"97c604b5-8566-4112-8914-b5259e64dde0","data":[]}
{"reqId":"ab1qEIxT_7J_MXQkfwGuBwAAAFQ","level":1,"time":"March 20, 2026 15:38:57","remoteAddr":"192.168.0.15","user":"bobw","app":"no app in context","method":"GET","url":"/nextcloud/ocs/v1.php/cloud/user?format=json","scriptName":"/nextcloud/ocs/v1.php","message":"The user config key files/quota is not defined in the config lexicon","userAgent":"Mozilla/5.0 (Windows) mirall/4.0.6 (build 20260122) (Nextcloud, windows-10.0.19045 ClientArchitecture: x86_64 OsArchitecture: x86_64)","version":"32.0.6.1","clientReqId":"58df0842-4098-4f17-8daf-31cb055828c7","data":[]}
{"reqId":"ab1qKm8i4BzFG_xnPX1oVwAAAJI","level":1,"time":"March 20, 2026 15:39:23","remoteAddr":"127.0.0.1","user":"bobw","app":"no app in context","method":"GET","url":"/nextcloud/ocs/v1.php/cloud/user?format=json","scriptName":"/nextcloud/ocs/v1.php","message":"The user config key files/quota is not defined in the config lexicon","userAgent":"Mozilla/5.0 (Linux) mirall/3.17.4daily (Nextcloud, fedora-6.19.7-200.fc43.x86_64 ClientArchitecture: x86_64 OsArchitecture: x86_64)","version":"32.0.6.1","clientReqId":"2654c018-7b24-4518-b0b0-9a71fbb1223d","data":[]}
{"reqId":"ab1qKG8i4BzFG_xnPX1oVQAAAII","level":1,"time":"March 20, 2026 15:39:21","remoteAddr":"192.168.0.13","user":"bobw","app":"no app in context","method":"GET","url":"/nextcloud/ocs/v1.php/cloud/user?format=json","scriptName":"/nextcloud/ocs/v1.php","message":"The user config key files/quota is not defined in the config lexicon","userAgent":"Mozilla/5.0 (Windows) mirall/4.0.6 (build 20260122) (Nextcloud, windows-10.0.19045 ClientArchitecture: x86_64 OsArchitecture: x86_64)","version":"32.0.6.1","clientReqId":"f1414249-7869-43c0-ad40-e4364908fab0","data":[]}
{"reqId":"ab1qMotDSkonnLKWbVroiAAAAM4","level":1,"time":"March 20, 2026 15:39:31","remoteAddr":"192.168.0.15","user":"bobw","app":"no app in context","method":"GET","url":"/nextcloud/ocs/v1.php/cloud/user?format=json","scriptName":"/nextcloud/ocs/v1.php","message":"The user config key files/quota is not defined in the config lexicon","userAgent":"Mozilla/5.0 (Windows) mirall/4.0.6 (build 20260122) (Nextcloud, windows-10.0.19045 ClientArchitecture: x86_64 OsArchitecture: x86_64)","version":"32.0.6.1","clientReqId":"99e2cf72-ca35-4570-9869-3717cecde004","data":[]}

Additional info

I suspect this behaviour is the cause real problems in my production environment.
It is easily reproducable, but may take thousands of attempts to capture.

The file write burst is generated from a script with an inner loop which is something like:

rm "${filename_prefix}"_${delete_filename_idx}.txt
xxd -l ${size} -p -c 0 /dev/urandom > "${filename_prefix}"_${filename_idx}.txt

where for each iteration

• size is incremented
• delete_idx is 2 behind filename_idx
• filename_idx is incremented modulo 3
  That means each file is a unique size and and a simple "ls -l" reveals the file "version".

The full log file is attached: wrap.log
It shows multiple failure modes:

1. Files do not catch up
2. Conflicts
3. Incorrect mtime

Also see #58978