[Bug]: notify_file_id push notifications are discarded for any folder other than the account root ("no matching file ids, ignoring")

[amferreiro]

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

Bug description

Which client version and operating system are you using?

Nextcloud Desktop Client 33.0.7, VFS mode.

Which server version and operating system?

Reproduced against two independent Nextcloud servers, ruling out a server-side cause:

Server A: Nextcloud 32.0.5.0
Server B: Nextcloud 33.0.5.1

Both have notify_push (Client Push) enabled and working — confirmed by the client successfully connecting to the websocket, authenticating, and receiving push notifications with correct file IDs (see logs below).

Bug description

Since the notify_file_id push notification model was introduced (replacing the older, more expensive notify_file model that triggers a full sync from the root on any change), the desktop client discards every notify_file_id push notification whose file IDs do not include the ID of the account's root folder.

In FolderMan::slotProcessFileIdsPushNotification (src/gui/folderman.cpp), the client receives the correct file IDs from the server, but then rejects them with:

no matching file ids, ignoring folder="" account=""

As a result, any change made to a file or folder that is not the account root — i.e. essentially every real-world change — is silently ignored by the push mechanism. The client falls back to the periodic Etag poll (remotePollInterval, 30–60s depending on server config) to eventually pick up the change, or to a manual/triggered sync.

This defeats the purpose of notify_file_id (near-instant, targeted sync) and reintroduces the exact polling delay it was meant to eliminate — but in a way that's easy to miss, because the periodic poll usually masks the problem. The consequence becomes very visible when a local edit happens to overlap with an un-propagated remote change: the client has no idea the remote file changed, syncs its own local edit, and only then discovers the mismatch — producing an unnecessary sync conflict and a (conflicted copy ...) file, even though the push notification with the correct file ID had already arrived (and been discarded) well before the local edit was made.

Steps to reproduce

1. Set up a Nextcloud account with notify_push (Client Push) enabled on the server.
2. Sync a folder structure with at least one subfolder below the account root (e.g. Root/Subfolder/file.txt).
3. Run the desktop client with --logdebug --logfile --logflush.
4. Leave the client fully idle (do not touch anything locally).
5. From a different client, or from the web UI, modify Root/Subfolder/file.txt.
6. Observe the debug log.

Expected behavior

The client receives the notify_file_id push notification containing the file ID(s) of the changed file/folder, recognizes that a synced folder is affected (independently of whether the account root's own ID is included), and schedules a sync — ideally a partial/targeted one — promptly.

Which files are affected by this bug

Nueva carpeta/test.txt

Operating system

Windows

Which version of the operating system you are running.

Windows 11

Installation method

Official Windows MSI

Nextcloud Server version

33.0.5.1 && 32.0.5.0

Nextcloud Desktop Client version

33.0.7

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
• LDAP or Active Directory
• SSO - SAML
• Other

Nextcloud Server logs

Actual behavior:
The notification is received correctly but discarded outright because it doesn't include the root folder's ID:

Received push notification: "notify_file_id [<fileId>]"
[handleNotifyFileId] File-ID push notification arrived
[slotProcessFileIdsPushNotification] received notify_file_id push notification account="<account>" fileIds=QList(<fileId>)
[slotProcessFileIdsPushNotification] no matching file ids, ignoring folder="<N>" account="<account>"

No sync is scheduled as a result of this notification. The change is only picked up later via the Etag poll timer or a manual sync.

Server A (Nextcloud 32.0.5.0), account root folder="1"

2026-07-13 12:34:47:223 [info] Received push notification: "notify_file_id [603493314,615938570]"
2026-07-13 12:34:47:223 [debug] [handleNotifyFileId] File-ID push notification arrived
2026-07-13 12:34:47:223 [info] Received push notification for file id changes, file count: 2
2026-07-13 12:34:47:223 [debug] [slotProcessFileIdsPushNotification] received notify_file_id push notification account="<account>@<serverA>" fileIds=QList(603493314, 615938570)
2026-07-13 12:34:47:223 [debug] [slotProcessFileIdsPushNotification] no matching file ids, ignoring folder="1" account="<account>@<serverA>"



Server B (Nextcloud 33.0.5.1), account root folder="2" — same client instance, different account

2026-07-13 13:12:23:801 [debug] [slotProcessFileIdsPushNotification] received notify_file_id push notification account="<account>@<serverB>" fileIds=QList(8990247)
2026-07-13 13:12:23:801 [debug] [slotProcessFileIdsPushNotification] no matching file ids, ignoring folder="2" account="<account>@<serverB>"

Additional info

No response

[amferreiro]

Possible root cause

SyncJournalDb::hasFileIds() (src/common/syncjournaldb.cpp) queries the local SyncJournal like this:

"SELECT 1 FROM metadata, json_each(?1) file_ids WHERE CAST(metadata.fileid AS INTEGER) = CAST(file_ids.value AS INTEGER) LIMIT 1;"

The fileIds coming from the notify_file_id push notification are passed into this query as-is (raw integers), without the account identifier appended to them. But metadata.fileid in the local SyncJournal is not a plain integer — it has an account/storage identifier concatenated to it.

The push notification for the same file arrived with fileIds=QList(8990247) — matching the numeric prefix of the local fileid exactly, with everything after it being the extra suffix. So CAST(metadata.fileid AS INTEGER) and CAST(file_ids.value AS INTEGER) are never comparing the same value, and the match in hasFileIds() essentially never succeeds for anything other than whatever bypasses this query (the account root).

[koenbokern]

Maybe this could explain the issues I had with syncing anything with desktop 33.0+ on Windows (or any such version in combination with problematic server or app changes). None of my web changes are recognized without a manual sync button press, but now for the first time I could sync something without a manual trigger: a new folder in the account root (custom Project folders as provided by the Research Drive service by SURF). I mentioned these problems to @i2h3 previously. I hope this can be prioritized if this is the cause. Although no changes are detected after 30-60 seconds with a traditional poll rate.

[i2h3]

The Windows VFS implementation is technically a completely different subsystem and independent from the macOS file provider, there is no overlap at all. Sorry, I cannot help in this regard.

[amferreiro]

Reproduced on Windows 33.0.7, both VFS and classic sync. Tried on macOS and it seems to work correctly there, though I haven't tested it as thoroughly as on Windows.

Severity:
This can mean staying out of sync for a long time, not just a short delay. A PC that mostly receives changes from other devices or shared folders, and rarely makes local edits itself, may not pick up remote changes on its own at all until something else (a manual sync, a restart, or an unrelated local edit) happens to trigger one. This is especially relevant for multi-PC setups or shared folders where changes often come from elsewhere.

[koenbokern]

I can confirm that making local changes actually does initiate a sync that brings changes I was otherwise missing. This may explain why admins like me (and other types of users that fit your description) who rarely add local content notice these issues.

[amferreiro]

Found the root cause: Legacy instanceid parsing

After digging a bit deeper into why this happens on some servers but not others, I found the pattern. It boils down to how the instanceid is parsed/casted in the client's logic:

• Modern instances (post-2014, e.g., starting with oc...): Work perfectly. Since they begin with a letter, any loose integer casting stops immediately at the first character and safely defaults to 0, preventing any accidental ID matching.
• Legacy instances (pre-2014, starting with digits): Trigger this bug. Because the instanceid starts with numbers before the first letter, the casting logic extracts those leading digits as a valid integer, which then conflicts with the folder/file ID matching in FolderMan::slotProcessFileIdsPushNotification.

To address this, there are two potential paths:

1. Client-side fix (Preferred): Update the desktop client's parsing logic to safely handle these legacy, digit-starting instanceid formats so they don't get partially cast to integers during the folder/file ID comparison.
2. Server-side workaround: For admins facing this, it would be incredibly helpful to know if there is a safe, documented way to change/migrate the instanceid in config.php to a modern oc... format without breaking existing client sync connections, active sessions, or storage paths.

Any guidance on which path is better or how we can safely address this would be greatly appreciated!

[koenbokern]

Correction of comment below: a file inside a new folder residing in root is synced but possibly only during an extended sync time window when the folder is already created and the green checkmark is visible. After waiting a bit after creating a folder in root the new content in that folder does not sync from web without manual trigger like described in this issue.

Original comment (last 2 sentences are still relevant):

@amferreiro with my problem the first file in a previously empty folder (residing in the root folder of my Nextcloud sync folder) is pushed, but not any subsequent new file. Does this comply with your hypothesis? Our Nextcloud instance was only created last year though and a conversion of an ownCloud instance of a service that provided us an instance since 2021. Since I'm not a technical server admin I can not check the instanceid.

[amferreiro]

@koenbokern I don't think it's quite the same pattern as what we found. In our case, changes outside the root never trigger a sync via push — consistently.
In a test, changing the instanceid fixed the push notification issue for us, so we're pretty sure that was the cause on our end. If you ever get access to check occ config:system:get instanceid, that would confirm whether you're hitting the same issue or something else.

[koenbokern]

@koenbokern I don't think it's quite the same pattern as what we found. In our case, changes outside the root never trigger a sync via push — consistently.
In a test, changing the instanceid fixed the push notification issue for us, so we're pretty sure that was the cause on our end. If you ever get access to check occ config:system:get instanceid, that would confirm whether you're hitting the same issue or something else.

Thank you for the reply. As my correction mentioned I hope this may still be the same problem since the correct sync of files inside the folder in root only happens right after the creation of a folder in root (and the creation of that file right after). Maybe a sync is still active somehow (not a dev). For the rest the problem seems to be same except that our instance is newer than the affected category you mentioned. I'm hoping for a fix, but I may ask our service provider for input (later in summer).