New items from other devices do not appear

[udoschmitz]

Summary

When a file is uploaded to the Nextcloud server from another device (confirmed visible in the web interface), it does not appear as a Virtual File placeholder on a second macOS device. The Desktop client reports "Everything is synced" with no errors. The only working fix is to disable and re-enable Virtual Files entirely, which forces a full re-enumeration from the server.

Environment

• Nextcloud Desktop Client: 3.3.0.5
• macOS: 15.7.6 (Sequoia)
• Hardware: MacBook Air M2 (Apple Silicon)
• Virtual Files mode: Enabled (macOS File Provider Extension)
• Nextcloud Server: self-hosted

Steps to Reproduce

1. Device A (old Mac, classic sync): Copy a new file into the Nextcloud sync folder
2. Wait for the file to upload — confirm it is visible in the Nextcloud web interface
3. On Device B (MacBook Air, Virtual Files enabled): Open the same folder in Finder or Terminal
4. The file does not appear as a Virtual File placeholder

Expected Behavior

The new file should appear as a placeholder (Virtual File) on Device B within a reasonable time after the upload to the server is complete.

Actual Behavior

• The file is missing. Running ls in Terminal on the affected folder returns results without the new file.
• The Desktop client shows no errors and reports "Everything is synced."
• No activity for the specific file is shown in the client's activity log.
• The file is clearly present on the server (visible in web interface).

Workaround

Disabling Virtual Files in the Desktop client and immediately re-enabling it triggers a complete re-enumeration from the server, after which the file appears correctly.

This workaround is disruptive: all local placeholders are removed and must be re-fetched, which takes considerable time depending on the number of files.

What Does NOT Help

• Restarting the Nextcloud Desktop client
• Running killall -9 fileproviderd (the daemon restarts but continues to return stale/incomplete listings)
• Waiting — the file never appears on its own without the disable/re-enable cycle

Additional Context

This appears to be a recurring issue with the macOS File Provider integration. Related reports:

• [Bug]: Support Account Domains Matching Common Bundle Extensions #7979 — Virtual Files fail to sync / appear on macOS
• [Bug]: 3.17.0 - MacOS Finder shows “Nextcloud is signed out” for Virtual Files domain; client UI stuck at “0.00 GB of 0.00 GB” #8599 — Finder shows "Nextcloud is signed out" while client reports OK
• https://help.nextcloud.com/t/macos-virtual-files-not-being-synced/231796
• https://help.nextcloud.com/t/ongoing-problems-with-macos-virtual-file-sync/232910

The root cause seems to be that fileproviderd caches the folder enumeration and does not reliably poll the server for changes, while the Desktop client considers its own upload queue empty and reports "synced" — creating a false sense of consistency. A targeted re-enumeration of specific remote folders (without requiring a full Virtual Files reset) would solve this.

[i2h3]

This appears to be a duplicate of #9688. 🤔 In general, I cannot reproduce this problem. In simple setups this works fine and reliably. Hence the devil must be in the detail(s).

The new file should appear as a placeholder (Virtual File) on Device B within a reasonable time after the upload to the server is complete.

@udoschmitz Because you have not provided any information on your server configuration, what is "reasonable" to you? If you do not have push notifications configured, the macOS desktop client polling usually takes up to 30 seconds to discover remote changes.

The links in "Additional Context" section are completely unrelated to the problem described here and outdated. Is this issue opened with the help of AI? 😅

The assumptions made about fileproviderd are also false. That is the central macOS service and host for all file provider extensions regardless of vendor. It manages the macOS side of the synchronization state as intended and documented in the official API documentation. Killing it does not influence the synchronization process of our file provider extension or the user interface of the independently running main app.

Since I fixed the push notification listening and polling earlier this year by leaving that to the main app (because it used to do that already reliably and a file provider extension is the wrong place to do that due to its in continuous lifecycle), the verdict is that there still might be a bug in the synchronization business logic of the extension which does not recognize and report changes correctly to macOS' file provider framework.

[udoschmitz]

This appears to be a duplicate of #9688.

Looks like it, although it’s not only with web created files. In my summary I explicitly mention that the file originated on my old Mac with Classic Sync.

Because you have not provided any information on your server configuration, what is "reasonable" to you? If you do not have push notifications configured, the macOS desktop client polling usually takes up to 30 seconds to discover remote changes.

Notify Push is configured. I would prefer faster, but thirty seconds would be absolutely reasonable 😄

I run NextCloud in a Docker container with Caddy on a Hetzner VPS:

NAMES	IMAGE
nextcloud-notify_push-1	nextcloud-ghostscript:latest
nextcloud-app-1	nextcloud-ghostscript:latest
nextcloud-db-1	mariadb:10.11
nextcloud-redis-1	redis:alpine
umami-app-1	ghcr.io/umami-software/umami:postgresql-latest
umami-db-1	postgres:15-alpine
caddy-caddy-1	caddy:latest

Nextcloud Hub 26 Winter (33.0.3)

(Please ask if you want to know more about my configuration.)

The links in "Additional Context" section are completely unrelated to the problem described here and outdated. Is this issue opened with the help of AI? 😅

Yes, of course it is. But I think I found those issues with my own research. 🙃

The assumptions made about fileproviderd are also false. That is the central macOS service and host for all file provider extensions regardless of vendor. It manages the macOS side of the synchronization state as intended and documented in the official API documentation. Killing it does not influence the synchronization process of our file provider extension or the user interface of the independently running main app.

Well, as the client is showing that I synced the file

and it shows up on Web

but not on Device B (MacBook Air, Virtual Files enabled)

I assumed that the problem was with the connection to the Finder.

Since I fixed the push notification listening and polling earlier this year by leaving that to the main app (because it used to do that already reliably and a file provider extension is the wrong place to do that due to its in continuous lifecycle), the verdict is that there still might be a bug in the synchronization business logic of the extension which does not recognize and report changes correctly to macOS' file provider framework.

@i2h3 Please tell me what I need to provide to help you.

(This comment was written without any help by AI)