A FileProvider error names a number. Which cloud app failed?

What the domain tells you

A domain in a macOS error says which part of the system is reporting. NSFileProviderErrorDomain says the FileProvider service is reporting a failure from one of its provider extensions — small pieces of your cloud apps that run inside macOS. The failure belongs to that provider's operation: an upload, a download, a sign-in check.

That rules out two common wrong turns. It is not macOS itself breaking, so reinstalling macOS fixes nothing. And it is not one single cause with one fix, so a remedy from a Dropbox thread may be wrong for the same number in Nextcloud.

The codes Apple documents (-1000s)

Apple's FileProvider error list defines the low numbers, and these mean the same thing in every app. The ones readers meet:

1. -1000 — not signed in. The provider's account needs attention: sign back in inside that provider's app — except iCloud Drive, whose sign-in lives in System Settings under your Apple Account.
2. -1003 — storage full. The cloud account (not necessarily your Mac) has no room. Free space in that provider or make room on the Mac if it keeps local copies.
3. -1004 — server unreachable. The Mac cannot reach the provider: connection first, outage pages second, account last.
4. -1005 — item not found. The file or folder the operation named is already gone on the other end. Sync the parent folder and look again before recreating it.

These four come from Apple's published FileProvider error list. Outside the -1000s, numbering is each provider's own — that is where the rows below come from.

The codes each provider defines (-2000s, -5000s)

Apple leaves the higher numbers to the providers, so the same number recurs with different meanings. What has actually been observed, provider by provider:

1. -2005 with Dropbox — often a harmless .dropbox system file the app maintains itself. Dropbox's own community notes say deleting it can cause app problems. Leave it alone.
2. -2005 with Nextcloud — failed uploads, including large files that fail immediately. Same number, real failure: check the file's size and the upload, not the system file.
3. -2010 with Dropbox on recent macOS — reported with Tahoe. Provider-version territory: update Dropbox before anything else.
4. -5008 with iCloud Drive — seen right after clean macOS installs while documents download. Give the first full download time to finish before diagnosing.
5. -5009 — reported without a published explanation; one August 2026 thread suspected an iCloud outage without confirming it. Undocumented means undiagnosed: work the steps above rather than the number.
6. -1002 with Proton Drive — seen in File Provider migration failures (observed with that provider, not on Apple's published list). Migration-time state: check the provider's migration status, not individual files.

Each row above says where it was seen, because an undocumented number has no universal meaning to state. New codes earn rows when they are observed with a provider, not before.

Find which provider owns the failing files

When the dialog does not name the app, the location usually does. iCloud Drive appears in Finder's sidebar under Locations. Dropbox, OneDrive, Google Drive, and Nextcloud each keep their own top-level folder unless you moved it. A failure inside one of those places belongs to that provider — with one caveat for shared or moved folders, where the path alone cannot tell.

% ps -axo comm | sort -u | grep -iE 'dropbox|onedrive|googledrive|nextcloud|proton|fileproviderd|bird|cloudd' | head -10

Dropbox
fileproviderd
bird

The provider processes running now. fileproviderd is Apple's service itself; bird looks after iCloud Drive documents. The brand names are the providers' apps. What is absent matters less: provider extensions can start on demand, so a missing app process means nothing is active right now, not that syncing is impossible.

The log command can show FileProvider activity naming the provider, but its output is verbose and needs the failure happening while it records. The process list above is the faster first read.

What Noah can determine on this Mac

NoahNoah can read a ranked list of the five processes — the programs your Mac is running — that are using the most processor. That shows whether fileproviderd or a provider's app is working hard right now. Noah can read the recent unified log, where FileProvider entries can name the provider that failed. And Noah can list which cloud apps are installed on this Mac, so the failing folder can be matched to its owner.

What Noah cannot see: the inside of a provider's sync engine, or that provider's server-side state. No tool on the Mac reaches those. So Noah diagnoses down to the provider and the failing operation, and stops there — anything beyond that is the provider's status page and support, not more local digging.

Steps to leave for last

Do not delete a provider's system files to clear a number. The .dropbox case above is the warning: removing it can break the app. The same caution holds for anything inside a provider's folder you did not put there.

Do not unlink the account, reinstall the provider, or turn Files on Demand (or its equivalent) off and on as a first step. Each of those can force large parts of the library to sync again, which takes hours — they are last resorts after sign-in, storage, and connection check out.

Fixif one file fails while the rest sync, start with the item, not the account: duplicate the file's contents elsewhere and remove the original from the synced folder. When the sync settles, put it back. Providers choke on single items — names with odd characters, zero-byte files, permission tangles — and an item that syncs everywhere except one Mac was never an account problem.