Dropbox on Linux and shared folders: what actually works in 2026

Decision. Run the official Dropbox client on Linux — btrfs, zfs and xfs are supported filesystems in 2026, so a btrfs root is not a blocker [1]. Do not try to point Windows Dropbox and Linux Dropbox at one shared partition: it is impossible, not merely unsupported [2]. And move your source repos out of Dropbox — Dropbox is not aware of git’s on-disk format and concurrent changes “can result in a corrupted Git repository” [3] ⭐ 3.1k. The obvious escape hatch closed in July 2026: Maestral, the main open-source client, is archived [4] ⭐ 3.3k.

Filesystems: official policy in 2026

The ext4-only rule is history. Dropbox announced in August 2018 that from 7 November 2018 only ext4 would sync on Linux [5], because the client stores per-file identity in extended attributes and wanted a single guaranteed xattr implementation [6]. It reversed course in build 77.3.127 (July 2019), restoring zfs, xfs, btrfs and eCryptFS [7].

Current official policy — the requirement is on the filesystem holding the Dropbox folder, not the root filesystem [1]:

“A Dropbox folder on a hard drive or partition, formatted with one of the following system types: ext4, zfs, eCryptFS (back by ext4), xfs, btrfs”

Point the client at an unlisted filesystem and it refuses to start syncing rather than degrading — the client checks the filesystem type at the Dropbox folder path. The community workaround is dropbox-filesystem-fix ⭐ 141, an LD_PRELOAD shim that patches the detection call [8]. Treat it as dead: the repo was archived in November 2025, is tested only up to client 89.4.278, and its author’s own advice was to switch to Maestral [8] — which is itself now archived [4] ⭐ 3.3k.

⚠ The btrfs snapshot conflict is real, but it is not a filesystem-support problem

btrfs is supported. The collision is with snapshot rollback semantics. Dropbox has no notion of “this whole tree just went back in time”: rolling back a subvolume that contains ~/Dropbox presents the client with a mass of deletions and reverted files, which it dutifully pushes upstream. In a shared folder that is not a local event — “If you delete a file inside a shared folder… that file disappears from the shared folder for everyone” [9]. This is an inference from documented delete semantics, not a documented Dropbox statement, but the failure mode is exactly what makes it dangerous.

Mitigation: put ~/Dropbox on its own btrfs subvolume that Timeshift/snapper do not snapshot, and use Dropbox’s own version history / Rewind as the time machine for that tree instead [10].

Feature parity vs the Windows client

The Linux client’s page carries a live warning — “The Dropbox desktop app for Linux is changing” — with dependency floors of GTK 2.24, GDK 2.24, Glib 2.40 and LibAppIndicator 12.10 (page last updated 9 February 2026) [18]. Dropbox ships no systemd unit; autostart is handled by dropbox autostart y writing an XDG autostart entry [15]. A user unit calling ~/.dropbox-dist/dropboxd is the standard headless pattern [17].

Net: the Linux client’s sync engine is at parity. What is missing is online-only files — which matters exactly when a shared folder is bigger than your disk.

Shared folders on Linux

Shared folders behave identically to Windows at the account level; the Linux-specific pain is in what you cannot do about size and what you can accidentally do to collaborators.

• Quota. A shared folder counts against the quota of every member, unless all members are on the same Standard/Advanced/Enterprise team or Family plan, where it counts once [19].
• Folder larger than your disk. With no Smart Sync on Linux [11], selective sync is the only lever — and it is folder-granular, so a large shared folder with a few small files you need is all-or-nothing [13]. Deselecting is per-device, so your Windows install can keep the full copy [13].
• Deletes are global. Edit permission means your delete is everyone’s delete; permanent deletion needs folder ownership [9].
• Conflicted copies. Three documented causes: two people editing simultaneously, someone editing offline while another edits online, and a file left open in an auto-saving app. The loser is renamed with the editor’s username, “conflicted copy” and the date [20]. ⚠ A dual-booter is two members in this model: an editor open in Windows when you reboot into Linux produces exactly the “left open on another user’s computer” case.
• Device limit. Dropbox Basic caps at three linked devices — a Windows install and a Linux install on one machine consume two of them [21].

Dual boot: can Windows and Linux share one Dropbox folder?

No. Not “unsupported” — arithmetically impossible under current policy. Windows Dropbox requires NTFS; Linux Dropbox requires one of ext4/zfs/xfs/btrfs/eCryptFS and NTFS is not on that list [1]. Since the 2018 filesystem restrictions there is no filesystem the two clients both accept, which is precisely how the Dropbox community answers it [2].

The only correct dual-boot arrangement is two independent Dropbox folders — C:\Users\you\Dropbox on NTFS and /home/you/Dropbox on ext4/btrfs — both syncing to the same account through the cloud, and never booting one while the other has unsaved open files. Costs two device slots [21] and a second full local copy.

Source code in Dropbox: don’t

Every one of these bites harder in a shared folder, because the blast radius includes other people.

Symlinks. Dropbox syncs a symlink pointing outside your Dropbox as “individual symlink files, and don’t sync the files referenced by the symlink” [22]. Worse for a mixed team: Windows Dropbox does not support symlinks or junctions at all and flags them with error indicators [22]. So the classic “symlink node_modules outside Dropbox” trick leaves your Windows collaborator with a broken artefact in their tree.

Case collisions. Dropbox’s namespace is case-insensitive — “you can’t have a file called Hello.doc and one called hello.doc” [24]. Linux filesystems are case-sensitive, so a repo containing Makefile and makefile, or a rename that only changes case, gets mangled on the way through Dropbox [23]. Also note \ / : * ? " < > | are restricted and names cap around 255 characters including path [34].

.git corruption. The authoritative statement comes from git-remote-dropbox’s author: “The desktop client is not aware of how Git manages it’s on-disk format, so if there are concurrent changes or delays in syncing, it’s possible to have conflicts that result in a corrupted Git repository” [3] ⭐ 3.1k. Packfile rewrites during gc, HEAD/index churn and ref updates are all racy against a background syncer.

Churn and watches. node_modules, bin/, obj/ and .next/ generate thousands of short-lived files. Each watched directory costs one inotify watch; the historic default max_user_watches was 8192 and Dropbox support recommends 100000, though kernels ≥5.11 auto-scale to 1048576 on machines with ≥8 GB RAM [25].

Exclusion is blunt. There is no .dropboxignore pattern file. Selective sync is folder-granular and per-device [13]; com.dropbox.ignored is set per file or folder, is not pattern-based, requires the Dropbox folder in its default location, and — critically — the ignored content “will be deleted from the Dropbox server and your other devices” [14]. ⚠ Inside a shared folder that means your collaborators lose it too [9].

Recommendation: code lives in git, hosted on a remote (GitHub/Gitea), cloned to ~/code outside Dropbox on every machine. Dropbox stays for documents and for the shared folders you cannot control. If a repo genuinely must live in a Dropbox shared folder, use git-remote-dropbox ⭐ 3.1k, which talks to the Dropbox API directly and does not require the desktop client [3].

Alternatives

Reading the table:

• Maestral is out. It was the answer to “official client won’t run on my filesystem” and to the 3-device cap, but the repo was archived on 2026-07-28 with the site stating “As of June 2026, Maestral is no longer actively maintained” and warning the client works only “until certificates expire” [26] [4]. Do not build a migration on it.
• rclone is a copier, not a client. bisync does two-way sync but the manual is blunt: “Bisync is considered an advanced command, so use with care… or data loss can result” [28], and a third party adding a file mid-run can force a full --resync. Dropbox-specific limits apply too: mtimes only settable by re-upload, >10000-file directories can’t be purged directly [24]. Fine for scheduled one-way backup; wrong for a live shared folder with collaborators.
• Syncthing cannot replace Dropbox for shared folders. It has no server — “none of your data is ever stored anywhere else other than on your computers” [29] ⭐ 87.1k. It is the right tool for your own machines, and useless for a folder shared with someone else’s Dropbox account.
• dbxfs is the only “online-only” answer. A FUSE mount gives you the whole account without local disk, which is the Smart Sync gap [30] — but latency makes it unusable as a working directory, and its GitHub mirror is archived [31] ⭐ 690.
• Insync is the paid escape hatch for filesystem freedom plus real shared/team-folder support, at $39.99 once per cloud account with unlimited machines [32] [33].

Recommended arrangement

1. Official Dropbox client on Linux. btrfs root is fine [1]. Stick to Ubuntu or Fedora if you want supportability [18].
2. ~/Dropbox on its own btrfs subvolume, excluded from Timeshift/snapper. Snapshot rollback of a shared folder deletes files for collaborators [9]; use Dropbox version history for that tree [10].
3. Two separate Dropbox folders across the dual boot, syncing through the cloud. One shared on-disk folder is not possible [2]. Budget two of the three Basic device slots [21].
4. Never leave editors open across a reboot — that is the documented conflicted-copy trigger [20].
5. Move all repos to ~/code, outside Dropbox, and push to a git remote. Case collisions [23], broken symlinks on Windows peers [22] and .git corruption [3] are all avoided at once.
6. Selective-sync away oversized shared folders on the Linux side while Windows keeps the full copy — it is per-device [13]. Add dbxfs as a read-mostly window onto what you excluded [30].
7. Syncthing for ~/code and dotfiles between your own machines [29] ⭐ 87.1k, and a nightly rclone one-way copy of ~/Dropbox to homelab storage as an independent backup [24] ⭐ 58.8k. Reserve rclone bisync for cases you have read the limitations section for [28].
8. Budget for Insync only if you later need Dropbox on an unsupported filesystem or a distro Dropbox won’t run on [32].