macOS File Provider: remote changes take minutes to hours to arrive because every push notification triggers a sequential depth-1 PROPFIND scan of the whole working set (~2,850 folders) #11152

⚠️ Before submitting, please verify the following: ⚠️

• This is a bug, not a question or a configuration issue.
• This issue is not already reported on Github (I have searched for it).
• Nextcloud Server and Desktop Client are up to date.
• I agree to follow Nextcloud's Code of Conduct

Bug description

In File Provider mode, changes made on the server by other devices reach this Mac very slowly. The web UI shows them immediately. The push notification also reaches the Mac immediately. The File Provider extension then takes minutes, sometimes much longer, before it reports the change to macOS.

The logs show why. A push notification ("Received file ID changes for locally known metadata. Signalling enumerator.") does not lead to a lookup of the file IDs it contains. Instead it signals the working set, and the extension runs a working-set remote-change scan. That scan sends one depth-1 PROPFIND per materialised folder, sequentially, at roughly one folder per second. The folders that contain the change are not read first.

On this account the working set holds about 2,850 materialised folders. Most of them are archive folders that have not changed for months:

Request volume of the extension (NextcloudKit log, FileProviderExt/Data/Documents/Logs/):

Single unchanged folders are read again and again. Two folders in archive tree A, unchanged since March, were read 23 and 31 times on 2026-10-28.

Delay between push notification and delivered change batch, 2026-10-28 09:00–15:25 while the Mac was in use (domain log File Provider Domains/<domain>/Logs/*.jsonl): 190 push signals. The time until the next completed change batch (Reporting change batch … moreComing: false) was:

The next completed batch does not always contain the change, because a scan does not necessarily reach the affected folder (see the example below). So these figures are a lower bound. Over the whole log period since 2026-10-26 18:11 (evenings and nights included), p90 was 92 min and the maximum was 296 min.

Incomplete scans make it worse. When a single folder read fails, the scan logs Working-set remote-change scan was incomplete: N item(s) could not be read and were skipped; … Not advancing the working-set sync point past the undiscovered changes. Since 2026-10-26 the read failures were 726× 502 Bad gateway (nightly server backup window around 04:00), 262× -1009 and 188× -1005. Incomplete scans skipped up to 545 items. Since the sync point does not advance, the next scan starts over.

The working set cannot be reduced by the user. For a materialised folder, fileproviderctl evaluate reports capabilities = 603979839 (no allowsEvicting) and displayEvict = 0, so Finder offers no "Remove Download". Only "Reset File Provider Domain" empties the working set.

Concrete example (2026-10-28, CET)

A Markdown note in an Obsidian vault (<vault>/<folder>/<subfolder>/note.md), edited on a Windows desktop client (35.0.0, classic sync). Server timestamps are from audit.log, client timestamps from the extension logs.

Between 14:00 and 15:22 the Mac did not read <subfolder> once. During the same time it read hundreds of unchanged folders deep inside archive tree A.

The slow propagation has a direct consequence for anyone who edits the same notes on two machines: the Mac keeps an outdated copy for a long time, an app on the Mac writes it back, and the other client ends up with a conflict.

Steps to reproduce

1. Use File Provider mode with a large working set: many materialised folders, e.g. after opening a deep folder tree or after an app has scanned a large folder tree in the sync folder.
2. Change a file in a small, actively used folder from another device.
3. Watch the extension logs: the push arrives immediately, then the working-set scan walks through all materialised folders. The change appears only when the scan reaches its folder, or when an app on the Mac happens to open the file.

Expected behavior

• A push notification that carries file IDs should lead to a targeted lookup of those IDs (or of their parent folders) before, or instead of, a full working-set scan.
• A working-set scan should use the etag of a parent folder to skip unchanged subtrees instead of reading every materialised folder.
• A transient read error (5xx, network loss) on one folder should not force the next scan to repeat the whole working set.
• The user should be able to evict a folder tree ("Remove Download") so that it leaves the working set.

Which files are affected by this bug

All files changed on the server by other devices.

Operating system

macOS

Which version of the operating system you are running.

macOS 26.6.2 (25G83), Apple Silicon

Installation method

Official Installer for macOS 13 and later

Nextcloud Server version

34.0.5

Nextcloud Desktop Client version

35.0.0

Did this occur after an update or on a clean installation?

Major version update (i.e. 4.0.0 → 33.0.0)

Are you using the Nextcloud Server Encryption module?

No

Are you using an external user-backend?

• Default internal user-backend

Nextcloud Server logs

Nothing relevant. The server answers every PROPFIND within about a second (p99 ≤ 1 s); the delay is entirely client side.

Additional info

• Server: Nextcloud All-in-One 34.0.5, PostgreSQL, Redis, notify_push and files_lock enabled.
• The File Provider domain was reset on 2026-10-13 (see macOS File Provider: orphaned metadata of remotely deleted/moved folders is never purged, causing endless 404 parent lookups #11056). The domain Realm database is 115 MB again.
• The extension also logged 967 MaterializedEnumerationObserver: Updating item state to dataless. messages since 2026-10-26, which looks like the loop from macOS FileProviderExt: MaterializedEnumerationObserver re-marks the same items "dataless" in a non-converging loop, starving all sync operations on large accounts (34.0.1) #10558 (closed). It is not clear whether that is related.
• Related, but different: New items from other devices do not appear #10070 (new items take up to 91 min to appear), macOS Tahoe 26.5.1: Virtual Files reports "Everything synced" although server changes are not downloaded #10334 (server changes not downloaded), One unreadable folder silently stalls ALL remote→local sync (working-set scan aborts on first read error) #10442 (scan aborted on the first read error, fixed; now items are skipped but the sync point is not advanced), macOS FileProviderExt: MaterializedEnumerationObserver re-marks the same items "dataless" in a non-converging loop, starving all sync operations on large accounts (34.0.1) #10558 (dataless loop), macOS File Provider: orphaned metadata of remotely deleted/moved folders is never purged, causing endless 404 parent lookups #11056 (orphaned metadata, my earlier report).
• I can provide the full extension logs privately. They contain personal file and folder names.