Dropbox fails to start on Linux systems where /home is a symbolic link

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!