Dropbox Linux 272.4.3798 remained at “Starting…” in the CLI and “Connecting…” in the tray for days. The immediate cause on this machine was the FILEEVENTS watcher following an archived directory symlink from inside Dropbox to the user's home directory, which contains Dropbox itself.
Deleting only that obsolete symlink, then restarting the same client with the same account and metadata, immediately allowed normal indexing. No metadata reset, relinking, permission sweep, kernel change or selective-sync change was needed for this repair.
Environment
- CachyOS / Arch-derived Linux, x86_64.
- Running kernel: 7.2.9-1-cachyos.
- Official Dropbox daemon: 272.4.3798, AUR package 272.4.3798-1.
- Management CLI: dropbox-cli 2024.04.17-2.
- Btrfs, ordinary read/write home subvolume, noatime and zstd compression.
- Dropbox Business account with a team-space directory.
- An existing local tree migrated from Maestral. Maestral was stopped throughout; there were never two sync engines operating on the tree.
Trigger layout (paths anonymized)
/home/user/Team Dropbox/Member/archive/old-home/.gnome-desktop/Home directory -> /home/user
/home/user/Dropbox -> /home/user/Team Dropbox/Member
The first symlink takes traversal back to an ancestor containing the Dropbox tree. It was a forgotten historical shortcut, not an attempt to sync the entire home directory. The second convenience symlink points into Dropbox and remains present after the successful repair.
Evidence before repair
- One long-lived daemon PID for more than 24 hours, rather than a process crash/restart loop.
- Approximately 109% total CPU, predominantly the FILEEVENTS thread.
- RSS 78,454,264 KiB (~74.8 GiB), process swap 38,529,868 KiB (~36.7 GiB), with anonymous memory dominating. RSS high-water mark ~88.7 GiB.
- Approximately 111,124 inotify watches, including 7,129 on sysfs. The configured watch limit was 524,288, so watch exhaustion was not the immediate explanation.
- A nucleus SQLite copy with WAL/SHM passed quick_check, but local_tree, synced_tree and remote_tree each had only one entry; fs_linux_fileids was empty.
- Most .dropbox directory growth was proprietary logs, not a growing sync index. During short observation, log files appeared/disappeared while the DB inodes and sizes remained stable.
- Established TCP connections to Dropbox endpoints on port 443.
Controlled diagnostic restart
The existing account/state was preserved, Dropbox was stopped cleanly, and exactly one daemon was restarted under strace. The trace showed inotify_add_watch and openat paths such as:
.../Team Dropbox/Member/archive/old-home/.gnome-desktop/Home directory/.local/state/...
In the brief trace, 105,167 inotify_add_watch calls used paths through “Home directory”, versus 1,471 other calls. This directly demonstrates the watcher following the symlink out of the intended tree into unrelated home directories. We did not run a minimal reproduction in a new account, and do not claim to know the proprietary implementation's precise allocation mechanism.
Workaround
- Stop Dropbox.
- Enumerate symlinks without following them, e.g.:
find '/actual/Dropbox/root' -type l -printf '%p -> %l\n' - Identify directory links pointing to an ancestor of the Dropbox tree, or any other circular target chain.
- Preserve the offending link's target, then remove or break only that obsolete link if appropriate for the data. Review the effect on its cloud copy before changing synced items.
- Restart Dropbox with the existing state and account.
- Verify the obsolete symlink is absent in the cloud too. During a fresh migration, deleting an unindexed local item may simply cause its cloud copy to be downloaded again. That happened here: initial sync completed, then the cloud symlink was restored and out-of-tree watches returned. We confirmed the server item was FileMetadata with symlink_info.target pointing to the home directory (size zero), deleted that exact cloud symlink and the restored local link, then restarted. The permanent repair retains all other data.
On this machine, removing one obsolete archived symlink changed the daemon from days of “Starting…” to “Indexing 66,036 files” within about 15 seconds. RSS was initially ~333 MiB, then ~386 MiB after several minutes, with zero process swap and about 4,616 watches on Btrfs. After the durable cloud deletion and restart, there were no sysfs/procfs watches.
Do not blindly delete all symlinks or reset .dropbox. Do not set an ignore xattr on the symlink's target: this can affect an unrelated directory. Dropbox's ignored-files documentation also says ignoring removes the server copy and is not a team-account feature.
Validation
- Indexing now advances through a decreasing file count.
- Both directions passed byte-for-byte checks: a locally created file was uploaded by the official daemon and downloaded through the API; a separate API-created file was downloaded by the official daemon. The API check never started Maestral syncing.
- The repaired daemon returned to “Up to date” after its initial index and again within 23 seconds of a clean restart, without relinking or /corruptdball. After restart: RSS ~376 MiB, zero swap, 4,616 watches, all on the intended Btrfs filesystem. Both database copies pass full integrity_check.
- Both byte-for-byte transfer checks also passed after the restart. Temporary verification files were cleaned up, and the obsolete cloud symlink remains absent.
- A machine reboot has not yet been tested.
Earlier reports
A January 2020 Dropbox Community reply explicitly describes circular symlink traversal preventing sync:
https://community.dropbox.com/discussions/101001012/dropbox-is-stuck-syncing-after-an-update-what-can-i-do/389422/replies/392189
A newer Linux report describes similar “Starting…” and RAM/swap exhaustion, but does not prove a symlink cause:
https://community.dropbox.com/en/discussion/853964/dropbox-app-using-a-lot-of-memory-in-linux-kubuntu-25-10
Please confirm whether this is a known unfixed defect in the current Linux FILEEVENTS implementation and route it to the desktop engineering team. Even if directory-symlink traversal is unsupported, the client should detect and stop cycles, report the problematic path, and continue syncing unrelated content rather than silently consuming essentially unbounded memory during initialization.
Btrfs context
This machine previously encountered a separate filesystem-ID/credential problem. Linux 7.2.8 includes “btrfs: derive f_fsid with dev_t only when temp_fsid is active”; the current host's statfs f_fsid matches the corrected UUID/subvolume derivation. No /corruptdball recurred in this investigation. The symlink repair was performed under the same running kernel and metadata, so this report concerns the independent watcher traversal failure.
https://cdn.kernel.org/pub/linux/kernel/v7.x/ChangeLog-7.2.8
