[Bug]: File Provider becomes degraded after using “Download now” / “Keep downloaded” on macOS

[sjg2203]

⚠️ 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

On macOS Tahoe 26.4, using File Provider mode with Nextcloud Desktop 33.0.2 against a Nextcloud 33.0.1 server (PostgreSQL 18) can put the File Provider domain into a degraded state when using “Download now” and “Keep downloaded” on files/folders.
Once this happens, the File Provider database appears internally corrupted, the trash container metadata is missing, and macOS logs thousands of repeated errors. A popup also appears with the following message:

The operation couldn't be completed. Invalid argument
Invalid argument

The system provides no working way to reset the domain (fileproviderctl reset is a no‑op on macOS 26), so the only recovery is a full client wipe and reinstall.

Steps to reproduce

1. Install Nextcloud Desktop 33.0.2 from the official DMG on macOS 26
2. Ensure File Provider mode is active (sync root appears under ~/Library/CloudStorage/Nextcloud-...)
3. Sync a reasonably large tree of files and folders
4. In Finder, right‑click various folders/files in the Nextcloud mount and use “Download now” and/or “Keep downloaded”
5. Let the client run for a while (including some server‑side changes and deletions)
6. Observe system logs and File Provider behaviour over time

macOS Console shows thousands of repeated errors like:

No metadata for enumerated item found for NSFileProviderTrashContainerItemIdentifier.
The File Provider appears to be missing metadata for its own trash container.

The internal File Provider database appears degraded:

• Enumeration of trash fails repeatedly
• Error generation count increases steadily
• fileproviderctl reset -f and fileproviderctl reset -f daemon do not work on macOS 26 (they only print help text, no reset is performed)

The Nextcloud File Provider domain can get into a state where:
The extension is running (FileProviderExt.appex process is active).
The CloudStorage mount exists (~/Library/CloudStorage/Nextcloud-…).
But the domain is effectively stuck in a degraded state and cannot be repaired via documented tools.
The only reliable recovery path is:

• Quit Nextcloud
• Delete ~/Library/Group Containers/com.nextcloud.desktopclient
• Delete /Applications/Nextcloud.app
• Remove caches and preferences
• Reboot
• Reinstall the DMG and log in again

This is very destructive from a user‑experience perspective and not discoverable.

Expected behavior

Using “Download now” and “Keep downloaded” should not corrupt or degrade the File Provider database.
If the File Provider database becomes inconsistent, the client should detect the degraded state.
Either self‑heal or offer a safe “Reset integration” button that:

• Clears the File Provider metadata
• Rebuilds the domain cleanly

On macOS 26, where fileproviderctl reset is effectively unavailable, the client should provide its own recovery mechanism instead of leaving the user in a broken state.

Which files are affected by this bug

All

Operating system

macOS

Which version of the operating system you are running.

macOS Tahoe 26.4 (25E246)

Package

Official macOS Virtual files 12+ universal pkg

Nextcloud Server version

33.0.1

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

{"reqId":"JZW6goJY1xv1vyC9Il1F","level":2,"time":"2026-04-02T09:49:38+00:00","remoteAddr":"URL","user":"USER","app":"no app in context","method":"GET","url":"/settings/api/apps/media?fileName=https%3A%2F%2Fgithub.com%2Fnextcloud%2Ffirstrunwizard%2Fraw%2Frefs%2Ftags%2Fv32.0.0%2Fimg%2FNextcloud.webm","scriptName":"/index.php","message":"Slow dns_get_record detected","userAgent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/26.4 Safari/605.1.15","version":"33.0.1.2","data":{"timeSpent":"10.02193307876587"}}

Additional info

fileproviderctl dump on macOS 26 shows only iCloud Drive as a top‑level provider, but:
FileProviderExt.appex is running.
~/Library/CloudStorage/Nextcloud-… exists.
The system logs contain thousands of instances of:

No metadata for enumerated item found for NSFileProviderTrashContainerItemIdentifier
The error generation counter for the iCloud/FP domain increases over time.

(If you want, I can attach a fileproviderctl diagnose bundle and relevant Console logs.)

[i2h3]

This sounds like multiple problems at once. There might be a chance this is related to #9057. The trash detail needs closer examination.