Summary
"Unlink this Dropbox" / sign-out in the desktop client does not revoke the corresponding cloud-side device session. Each subsequent re-link creates a new entry in dropbox.com/account/security while previous ones remain. With N phantom sessions, the cloud fans out change notifications and content fetches N× to the only live machine, overwhelming DropboxFileProvider's serial XPC queue and deadlocking nucleus.sqlite3. All sync stops — CPU 0%, Finder badges frozen, and re-linking alone does not recover.
Environment
- macOS 26.4.1 (Darwin 25.4.0)
- Dropbox 250.3.3131, FileProvider extension 4018.101.1
- Pro account, same account signed in on two Macs sharing the same ComputerName ("MacBook Pro che")
Reproduce
- Sign in to the same account on Machine A and Machine B with the same ComputerName; edit overlapping folders concurrently.
- Over several months, unlink + re-link the client on Machine B six or seven times as sync issues arise (each creating a new ~/.dropbox/instanceN/).
- Eventually sync stops entirely on Machine B. Restarting Dropbox, rebooting, and re-linking do NOT recover.
Diagnostics
$ scutil --get LocalHostName
MacBook-Pro-che-5 # -5 suffix implies 5 prior mDNS name collisions
$ ls ~/.dropbox/ | grep instance
instance1 … instance7 # 7 reconnects accumulated
$ ps -p <FileProvider PID> -o pid,%cpu,etime
893 0.0 12:15 # pinned at 0% after an initial spike
$ timeout 15 fileproviderctl dump com.getdropbox.dropbox.fileprovider
alive (893) via ExtensionKit for: servicer for Dropbox
alive due to XPC calls
fetchContentsForItemWithID:... (no timeout), no progress
fetchContentsForItemWithID:... (no timeout), no progress
... [14 entries stacked on the same queue]
$ sqlite3 ~/.dropbox/instance*/sync_fp/nucleus.sqlite3 "PRAGMA integrity_check;"
Error: database is locked
$ sample <PID> 1 | grep -c "mach_msg2_trap|semaphore_wait"
28 # threads parked on synchronous XPC
Tree also accumulated 258 conflicted copies including three top-level Selective Sync conflict directories, compounding the fetch fan-out.
Hypothesized cause
Because the cloud device list retains every past session:
- Change notifications go to N devices; N-1 are phantoms that never ACK.
- fetchContentsForItemWithID XPC calls pile up on the live FileProvider's serial dispatch queue (one per phantom × affected item).
- Pending calls hold row locks on nucleus.sqlite3 WAL, starving new writes.
- A synchronous XPC between fileproviderd and DropboxFileProvider eventually parks on mach_msg2_trap, completing the deadlock.
What actually fixed it
- dropbox.com/account/security → removed every stale "MacBook Pro che" device session.
- killall DropboxFileProvider on the stuck machine (launchd restarts it).
Sync recovered without re-indexing. FileProvider immediately jumped to ~80% CPU and began draining the ~1.75 GB backlog.
Important: step 1 alone did not wake the stuck extension (XPC queue was still blocked locally). Step 2 alone would not have lasted — the phantom sessions would refill the queue within hours. Both were required.
Suggested fixes
- Unlinking should revoke the cloud device session, not merely log out locally. Present behaviour silently accumulates phantom sessions indefinitely.
- Warn on ComputerName collision when two active devices on the same account share a hostname. mDNS already appends -N suffixes to LocalHostName — that's a detectable signal.
- Collapse duplicate in-flight fetches: N outstanding fetchContentsForItemWithID calls against the same item ID should dedupe to 1.
- Surface FileProvider diagnostics in the GUI. Users currently have to know fileproviderctl dump and poke at ~/.dropbox/instanceN/sync_fp/ to see why sync stalled.
Happy to provide fuller fileproviderctl diagnose output (817 KB gzipped) privately if helpful.
