File changes in shared folder do not appear locally

[bu-nd]

⚠️ 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've searched it).
• Nextcloud Server and Desktop Client are up to date. See Server Maintenance and Release Schedule and Desktop Releases for supported versions.
• I agree to follow Nextcloud's Code of Conduct

Bug description

The File Provider Extension intermittently reports account not set up after a fresh account setup on 33.0.2. This causes certain container enumerations (e.g. Trash) to fail, while others succeed with the correct account context.
This appears to be a regression or incomplete fix of #9393, which was closed for the 33.0.0 milestone. The issue persists on 33.0.2 with a completely fresh installation (no upgrade/migration from older versions).

Key observations from the File Provider Extension debug logs:

• "Not providing enumerator for container with identifier [...] yet as account not set up" appears repeatedly — both for trash container and for specific file item identifiers.
• Other enumerations in the same session succeed and correctly resolve the account (e.g. "Set up enumerator." with full account and DAV URL).
• maybe a timing/race condition: the extension starts enumerating before the account is fully initialized. Some enumerations hit the uninitialized state, while later ones succeed.
• Trash-related operations also fail: "Did not find trashed item in trash, asking for a rescan" followed by "Tried to modify filename of already trashed item. This is not supported."

Practical impact: Changes made by other users in shared folders are not reliably reflected in Finder via VFS. The Nextcloud client activity feed shows the changes correctly (notify_push is active and working), but the File Provider Extension does not propagate them to the file system.

Steps to reproduce

1. Fresh install of Nextcloud Desktop Client 33.0.2 on macOS (no prior installation/migration).
2. Add an account connected to a Nextcloud server (managed Hetzner StorageShare in my case).
3. Let VFS / File Provider Extension complete initial enumeration (~500 GB, many files).
4. Observe debug logs: account not set up errors appear for some container enumerations.
5. Have another user modify or add files in a shared folder.
6. Changes do not appear in Finder. Client activity feed shows the changes correctly.
7. Removing and re-adding the account temporarily helps, but the problem returns within ~2 days.

Expected behavior

All container enumerations should use the fully initialized account context. Server-side changes detected via notify_push should be reflected in Finder via the File Provider Extension.

Which files are affected by this bug

All files managed by the File Provider Extension / VFS.

Operating system

macOS

Which version of the operating system you are running.

Sequoia 15.7.5

Package

Official macOS 12+ universal pkg

Nextcloud Server version

32.0.6

Nextcloud Desktop Client version

33.0.2

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

Fresh desktop client install

Are you using the Nextcloud Server Encryption module?

Encryption is Disabled

Are you using an external user-backend?

• Default internal user-backend
• LDAP/ Active Directory
• SSO - SAML
• Other

Nextcloud Server logs

N/A — managed instance, no server log access.

Additional info

• notify_push is active and working (changes appear in the client’s activity feed).
• ~500 GB of data, heavy VFS usage.
• The account has been removed and re-added multiple times; the problem consistently returns.
• Related: File Provider Extension not Learning about Changes on Server #9393 (closed for 33.0.0 milestone).
• Related: Yellow triangle when emptying the trash #9846 the triangle is also showing in the client icon. and similar [Bug]: macOS Nextcloud-3.17.0-macOS-vfs and later has severe sync problems #8694
• Debug archive available on request (contains file names from a shared workspace — prefer not to post publicly).
• an option like "Force re-enumerate" would be good for similar problems in the future

UPDATE 16.04.2026
A related issue: When a shared folder is moved to a different location via the web interface, the File Provider Extension continues to enumerate the old path and fails with NKError code 1. The new location does not appear in Finder.
Log excerpt:

"Set up enumerator." (with old path)
"Read of URL did fail." — NKError code 1
"Finishing enumeration for page with error."

Using "Remove Download" on the parent folder in Finder and restarting the client does not resolve this — the moved folder still does not appear at its new location.
It seems the File Provider Extension does not process server-side move/rename operations for shared folders during change observation.

[i2h3]

1. The guard statements about the account state not being set up yet in the run time of a file provider extension process are there to prevent a race condition, as you have suspected. They are fine and expected.
2. Currently, in this project, the file provider extension depends on the main app injecting credentials via interprocess communication. That usually happens slightly later after the extension process launched.
3. Other means to avoid the race condition are currently not possible for us in this project (keychain access groups).
4. The activity view fetches information from the server and is independent from local file system state. Even in case of classic sync, it may only be "enriched" by local events injected but the source of truth remains the server. Hence there is the possible inconsistency with the file provider domain.
5. There is no initial enumeration since before I joined the project. There is no "All container enumerations should use the fully initialized account context.". The number of files and their size on the server do not matter. Content is enumerated purely on demand, as requested through user interaction in Finder. In other words: Most enumeration (trash always is queried by the system because it is reported as supported by our client) is based on what a user or their apps actively browse in the local file system, not what actually is there on the server.

In summary, I understand this issue as another report about remote changes not being adopted properly. There might be something wrong in the logic of the file provider extension comparing local and remote state and reporting changes.

Note that it is out of question to do a full enumeration of remote content on setup. We did that in the past and it was removed intentionally with 3.17 (ifI recall correctly, it was before my time on team). It does not scale with WebDAV and in use cases with large remote structures this results in a flood of enumeration requests on the server by every connected client. The on-demand metadata enumeration will remain.