[Bug]: macOS File Provider: sync anchor stuck since the 34.0.1 upgrade, 200+ stream resets, remote changes never appear (uploads still work)

[pedrohfw]

Environment

• Nextcloud Desktop Client: 34.0.1 → 34.0.4 (upgraded 2026-09-21, no change in behavior)
• macOS 26.6.2 (Mac mini, Apple Silicon), File Provider / VFS mode (macFileProviderModeEnabled=true)
• Nextcloud Server 33.0.8 (managed hosting)
• Single account, ~716 GB. One library folder alone is 216 GB with ~830 subfolders at depth 2 and many more below (PDF collection).

Summary

Since around the 34.0.1 upgrade (2026-08-18/19) the extension has stopped advancing its change-enumeration anchor. Remote changes never appear locally; local changes still upload.

• Files created or moved locally are uploaded normally (fileproviderctl evaluate → isUploaded = 1 within a minute or two).
• Nothing new from the server is ever enumerated. A folder that received 31 files on the server between 2026-09-05 and 2026-09-19 (uploaded from iOS via WebDAV PUT) still shows 0 items in Finder / ls on 2026-09-21. Files moved server-side (WebDAV MOVE) never appear either. fileproviderctl evaluate on those folders says isDownloaded = 1; isMostRecentVersionDownloaded = 1.
• FileProviderExt sits at 97-99% CPU for days (same PID for 8+ days on 34.0.1). sample shows ~95% of the time on the "Realm notification listener" thread inside RealmSwift (GroupWriter::recreate_freelist, Array::alloc, do_write_deep, Allocator::translate). The domain .realm file is 315 MB.
• Killing FileProviderExt / restarting the client does not help. Right after a restart, new local items fail once with NSFileProviderErrorDomain Code=-1000 "You need to authenticate before accessing this item" until the client is relaunched a second time.

What fileproviderctl dump shows for the Nextcloud domain (2026-09-21, on 34.0.4)

+ FP anchor: <page:<nil> anchor:34.0.1|2026-08-19T16:57:23Z>
- scheduler: <l:com.apple.fileproviderd.stream-reset ⏳  registration:<from:2026-09-21 14:12:29 +0000 count:212>
              trigger:<from:2026-09-21 12:31:24 +0000 to:2026-09-04 18:19:20 +0000> ... watchers=com.nextcloud.desktopclient.FileProviderExt/...>
+ error generation: 36
pending-indexable-count: 30621

• The anchor fileproviderd holds for the domain is still 34.0.1|2026-08-19T16:57:23Z, i.e. the last successful enumerateChanges was on 2026-08-19, one day after the upgrade to 34.0.1. It did not move after upgrading to 34.0.4.
• fileproviderd has a stream reset pending with 212 registrations, first triggered 2026-09-04 (the day the folder stopped receiving files). Each reset implies a full re-enumeration of the domain.
• The only pending fs→fp operations are 84 fields:lastUsedDate updates on directories (dir sched:utility); no pending downloads.

What the extension is doing (~/Library/Containers/com.nextcloud.desktopclient.FileProviderExt/Data/Documents/Logs/log.txt, 34.0.4)

• Right after launch it retries DELETEs of three files that no longer exist on the server (they were deleted server-side two weeks ago) and gets AFError.responseValidationFailed(unacceptableStatusCode(404)). It also retries, every ~2 hours, an operation on a folder that was renamed away weeks ago (404 as well). These failures are never dropped.
• Then it walks the big library folder: a PROPFIND on a different subfolder every 3-4 s (~15/min for 14+ minutes and counting), i.e. a full tree walk, one request per directory. With thousands of directories this never completes before the next stream reset.
• In parallel it issues hundreds of GETs for file contents (513 in ~11 h) in folders nobody opened, presumably to satisfy indexing.
• No [WARN]/[ERROR] lines; all of the above is logged at [INFO].

The extension container's tmp had accumulated 36 GB / 53 leftover directories (__fpfsdocID(...)_* and 00000000oc9y7tre3s4o-style, dated 2026-07-21 … 2026-08-25, containing partial downloads). They were never cleaned up; I removed them by hand.

The client log (…/Preferences/Nextcloud/logs/*_nextcloud.log.0) also shows nightly bursts of Socket operation timed out / OperationCanceledError for ocs/v1.php/cloud/user (e.g. 37 on 2026-09-05 between 01:00 and 06:00) while the server answers status.php in ~0.7 s by day.

Steps to reproduce (as observed)

1. Large account (hundreds of GB, tens of thousands of directories) in File Provider mode, upgraded from 33.0.7 to 34.0.1.
2. Let it run. The anchor stops advancing; after ~2 weeks fileproviderd starts scheduling stream resets that never complete.
3. Upload files to the server from another device.
4. On the Mac the target folder never shows the new files, even after killall FileProviderExt, client restarts and upgrading to 34.0.4. Local edits/moves still upload.

Expected behavior

enumerateChanges should keep advancing the anchor; a stream reset should complete (or fail loudly) instead of looping for weeks; failed operations on items that returned 404 should be dropped; leftover temp directories should be cleaned up.

Workarounds tried

• killall FileProviderExt, client quit/relaunch: uploads resume, downloads stay dead, CPU back to ~99%.
• Upgrade 34.0.1 → 34.0.4 with a clean temp dir: same anchor, same loop.
• Keeping the server tidy through WebDAV MOVE/DELETE from another machine (the Mac never notices).

Related

• Persistent high CPU usage of FileProviderExt on MacOS #10097 (Persistent high CPU usage of FileProviderExt on macOS, closed as shipped in 34.0.1). The symptoms above appeared right after moving to 34.0.1 and persist on 34.0.4.
• [Bug]: Mac OS VFS: when fileproviderextdatabase.realm becomes large, Finder becomes unresponsive #7326 (large .realm makes Finder unresponsive).

[pedrohfw]

Follow-up after a domain reset (same day):

Workaround that fixed it — remove and re-create the File Provider domain for the same account, without removing the account or re-authenticating:

1. Quit the client, killall FileProviderExt.
2. Edit nextcloud.cfg: temporarily drop the 0\… keys of the [Accounts] section, launch the client. It notices the existing domain has no matching account and removes it (fileproviderdomainmanager.mm). macOS moves the files it considered not synced into ~/Library/CloudStorage/<domain name> (<date>).
3. Quit again, restore the original [Accounts] section minus 0\fileProviderDomainIdentifier=…, launch. The client creates a new domain (new UUID) for the same account, using the credentials already in the keychain.

Result: within ~10 s the folder that had been stuck showed all 31 server-side files, and fileproviderctl dump now reports FP anchor: <page:<nil> anchor:34.0.4|2026-09-21T17:21:38Z>; the extension idles at ~1% CPU.

What macOS kept aside from the old domain (never uploaded by the extension): 26,062 files / 5.5 GB, of which 25,898 are the contents of macOS packages (Photos Library.photoslibrary/…, *.numbers/…, *.pages/…) sitting inside a backup folder, plus Thumbs.db and Syncthing markers (both on the exclude list, expected). So the ~16k create-item operations stuck with NSFileProviderErrorDomain -2005 (cannotSynchronize) were package contents. It would be useful if the extension either synced package contents or dropped those operations instead of retrying them forever — they seem to be what kept the change stream from ever advancing.