Device
Dell XPS 15 9520
Operating System/Browser (if using the web)
Fedora 43 Kinoite
Dropbox App Version (if using the app)
v240.4.8493
Syncing Status
Up to date (workaround exists)
Question or Issue
I noticed this issue after installing Dropbox via Flatpak, but I confirmed it exists on the headless official version, too.
Fedora 43 Kinoite (and other atomic distros like Bazzite) keeps most of the root partition read-only, mounting a btrfs subvolume at `/home`, which is a symbolic link to `/var/home`. On my system, I see this:
alex@alex-laptop:/var/home/alex$ echo $HOME
/home/alex
alex@alex-laptop:/var/home/alex$ grep $USER /etc/passwd
alex:x:1000:1000:Alex Reinking:/home/alex:/bin/bash
alex@alex-laptop:/var/home/alex$ grep home /etc/fstab
UUID=b3440961-1f62-4818-a9c8-1b83b2c2c23f /home btrfs subvol=home,compress=zstd:1,x-systemd.device-timeout=0 0 0
After launching the Dropbox daemon, I am prompted to sign in. After doing so, Dropbox fails to create the ~/Dropbox directory, displaying the following error dialog:
One way to work around this is to manually resolve the symbolic link:
$ export HOME=$(realpath ~)
$ ~/.dropbox-dist/dropboxd
See more discussion here: https://github.com/flathub/com.dropbox.Client/issues/392
After doing this once, however, Dropbox is able to continue working; likely because the information in ~/.dropbox bypasses the broken file system check.
Please fix Dropbox's file system support check!
