Problems syncing on Bazzite with Linux.

Integration Affected
Bazzite Linux, KDE and Gnome Desktops
Device
Custom PC
Operating System/Browser (if using the web)
Bazzite Linux, Kernel 6.15.9-116.bazzite
Dropbox App Version (if using the app)
231.4.5570

Question or Issue

-- I downloaded Dropbox as usual but it says the following when attempting to Sync:

-- I've seen this happening only in Bazzite, I don't know if there are considerations given that is an inmutable distro and comes with btrfs filesystem by default. Which is weird because you supposedly support that filesystem.

-- Also, other users in the Bazzite forums have tried the following:

Interesting. Thank you for the detail, I am a staff software engineer familiar with linux (I run programming.dev actually), so the description helps, I’m just not familiar with a lot of the intricacies of linux, nor desktop linux. I’ve switched to cachyos and am trying to set up bazzite for my wife.

So I get the same output on Bazzite for those commands, so UB is at least consistent here. I do not understand what you mean by using flatseal to configure the Dropbox flatpak to use /var/home. There’s no reference to /home anywhere in flatseal, and it looks like the only thing I can change are permissions. When I click the Move button (which I would assume would let me actually point it at /var/home, nothing happens. I actually posted about this in the Universal Blue discord, with some of the other stuff I’ve tried:

**
Things I’ve tried:**

• adding permission in flatseal for app to access everything
• adding folder to /var/mnt/synco/lnsync/account to Other Files in flatseal (even though synco doesn’t exist)
• created a 100gb partition /run/media/sabrina/Dropbox , mounting it, adding it to flatseal’s Other Files and clicking Move in the dropbox dialog again.
• reinstalling
• running Dropbox with GSK_RENDERER=ngl flatpak run com.dropbox.Client. I’ll attach the logs I got for that, but it was a big nothingburger, even after clicking Move nothing shows up.
• running Dropbox with GSK_RENDERER=gl flatpak run com.dropbox.Client. Same deal (gl vs ngl)

I even have this bit in there:

the one thing that is always recommended is moving the dropbox folder from /home/user/Dropbox to /var/home, but I have the same error as the last link I provided. When I click Move nothing ever happens. It just closes the dialog with no further messaging.

If I run Dropbox from the cli, to get logs (dropbox’s debug logs are in binary for their ‘support tool’) then I get this, where nothing shows after clicking Move.

GSK_RENDERER=ngl flatpak run com.dropbox.Client
dropbox: load fq extension '/app/extra/.dropbox-dist/dropbox-lnx.x86_64-230.4.8797/cryptography.hazmat.bindings._openssl.abi3.so'
dropbox: load fq extension '/app/extra/.dropbox-dist/dropbox-lnx.x86_64-230.4.8797/cryptography.hazmat.bindings._padding.abi3.so'
dropbox: load fq extension '/app/extra/.dropbox-dist/dropbox-lnx.x86_64-230.4.8797/apex._apex.abi3.so'
dropbox: load fq extension '/app/extra/.dropbox-dist/dropbox-lnx.x86_64-230.4.8797/google._upb._message.cpython-38-x86_64-linux-gnu.so'
dropbox: load fq extension '/app/extra/.dropbox-dist/dropbox-lnx.x86_64-230.4.8797/psutil._psutil_linux.cpython-38-x86_64-linux-gnu.so'
dropbox: load fq extension '/app/extra/.dropbox-dist/dropbox-lnx.x86_64-230.4.8797/psutil._psutil_posix.cpython-38-x86_64-linux-gnu.so'
<frozen zipimport>:259: UserWarning: google.protobuf.service module is deprecated. RPC implementations should provide code generator plugins which generate code specific to the RPC implementation. service.py will be removed in Jan 2025
dropbox: load fq extension '/app/extra/.dropbox-dist/dropbox-lnx.x86_64-230.4.8797/tornado.speedups.cpython-38-x86_64-linux-gnu.so'
dropbox: load fq extension '/app/extra/.dropbox-dist/dropbox-lnx.x86_64-230.4.8797/wrapt._wrappers.cpython-38-x86_64-linux-gnu.so'
Gtk-Message: 09:28:00.323: Failed to load module "colorreload-gtk-module"
dropbox: load fq extension '/app/extra/.dropbox-dist/dropbox-lnx.x86_64-230.4.8797/cryptography.hazmat.bindings._openssl.abi3.so'
dropbox: load fq extension '/app/extra/.dropbox-dist/dropbox-lnx.x86_64-230.4.8797/cryptography.hazmat.bindings._padding.abi3.so'
dropbox: load fq extension '/app/extra/.dropbox-dist/dropbox-lnx.x86_64-230.4.8797/apex._apex.abi3.so'
dropbox: load fq extension '/app/extra/.dropbox-dist/dropbox-lnx.x86_64-230.4.8797/psutil._psutil_linux.cpython-38-x86_64-linux-gnu.so'
dropbox: load fq extension '/app/extra/.dropbox-dist/dropbox-lnx.x86_64-230.4.8797/psutil._psutil_posix.cpython-38-x86_64-linux-gnu.so'
dropbox: load fq extension '/app/extra/.dropbox-dist/dropbox-lnx.x86_64-230.4.8797/google._upb._message.cpython-38-x86_64-linux-gnu.so'
<frozen zipimport>:259: UserWarning: google.protobuf.service module is deprecated. RPC implementations should provide code generator plugins which generate code specific to the RPC implementation. service.py will be removed in Jan 2025
dropbox: load fq extension '/app/extra/.dropbox-dist/dropbox-lnx.x86_64-230.4.8797/tornado.speedups.cpython-38-x86_64-linux-gnu.so'
dropbox: load fq extension '/app/extra/.dropbox-dist/dropbox-lnx.x86_64-230.4.8797/cryptography.hazmat.bindings._openssl.abi3.so'
dropbox: load fq extension '/app/extra/.dropbox-dist/dropbox-lnx.x86_64-230.4.8797/cryptography.hazmat.bindings._padding.abi3.so'
dropbox: load fq extension '/app/extra/.dropbox-dist/dropbox-lnx.x86_64-230.4.8797/apex._apex.abi3.so'
dropbox: load fq extension '/app/extra/.dropbox-dist/dropbox-lnx.x86_64-230.4.8797/google._upb._message.cpython-38-x86_64-linux-gnu.so'
dropbox: load fq extension '/app/extra/.dropbox-dist/dropbox-lnx.x86_64-230.4.8797/psutil._psutil_linux.cpython-38-x86_64-linux-gnu.so'
dropbox: load fq extension '/app/extra/.dropbox-dist/dropbox-lnx.x86_64-230.4.8797/psutil._psutil_posix.cpython-38-x86_64-linux-gnu.so'
<frozen zipimport>:259: UserWarning: google.protobuf.service module is deprecated. RPC implementations should provide code generator plugins which generate code specific to the RPC implementation. service.py will be removed in Jan 2025
dropbox: load fq extension '/app/extra/.dropbox-dist/dropbox-lnx.x86_64-230.4.8797/tornado.speedups.cpython-38-x86_64-linux-gnu.so'
dropbox: load fq extension '/app/extra/.dropbox-dist/dropbox-lnx.x86_64-230.4.8797/wrapt._wrappers.cpython-38-x86_64-linux-gnu.so'
Gtk-Message: 09:28:06.961: Failed to load module "colorreload-gtk-module"

At this point this seems like maybe I should be contacting Dropbox though, but I’ve seen so many other posts where people got this working that I just assumed it must be on my side.

-- Other user adds:

That is another view of the symptom. The reality is that there is nothing to move!

But the code inside of the flatpak:

• doesn’t understand the metadata it is getting from the composefs fs type
• is not expecting /home to be a symlink and so is not doing the equiv of performing a stat command the follows the symlink.

For example, look at the difference of this output:

$ stat /home
  File: /home -> var/home
  Size: 8             Blocks: 8          IO Block: 4096   symbolic link
Device: 0,39    Inode: 563         Links: 1
Access: (0777/lrwxrwxrwx)  Uid: (    0/    root)   Gid: (    0/    root)
Context: system_u:object_r:home_root_t:s0
Access: 1970-01-01 00:00:00.000000000 +0000
Modify: 1970-01-01 00:00:00.000000000 +0000
Change: 1970-01-01 00:00:00.000000000 +0000
 Birth: -

vs dereferencing the symlink like this:

$ stat -L /home
  File: /home
  Size: 28            Blocks: 0          IO Block: 4096   directory
Device: 0,50    Inode: 256         Links: 1
Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Context: system_u:object_r:home_root_t:s0
Access: 2025-08-25 20:30:54.504715317 +0000
Modify: 2024-12-28 13:11:12.910724872 +0000
Change: 2025-08-24 18:42:06.380999950 +0000
 Birth: 2024-12-28 12:57:19.448791400 +0000

I suspect they are not recognizing that `/home` is a symlink so they are querying the wrong filesystem and failing.

Thanks for the kind words.

-- Another user has a theory but no action Plan:

Earlier this year, upstream (Fedora) changed the root (/) filesystem type to composefs for reasons.

This is not a widely recognized filesystem type across the Linux landscape. And it has limitations. One of those limitations is what is being experienced in this case - namely, the DropBox flatpak does not recognize the FS type and does not know what to do with it.

The workaround I suggested was to bypass the configuration of the flatpak by modifying the config (using flatseal) to point to /var/home/userid instead of /home/userid.

The reason that workaround is effective is because:

TL;DR - flatpaks not based on one of the Fedora Atomic Desktop offerings do not understand the composefs file system type. The workaround is effective because on Universal Blue systems /var/home is of type btrfs instead, which is widely recognized.

• / is of filesystem type composefs and that fs type is not widely known outside of the Fed-a-verse
• /home is just a symlink to /var/home
• /var/home is of type btrfs instead - which is widely recognized

So using /home vs /var/home provide different results because they are of different fs types and the type of the / filesystem is not widely known (yet).

$ mount | grep 'on / ' | head -1
composefs on / type overlay (ro,relatime,seclabel,lowerdir+=/run/ostree/.private/cfsroot-lower,datadir+=/sysroot/ostree/repo/objects,redirect_dir=on,metacopy=on)

$ mount | grep 'on /var/home ' | head -1
/dev/nvme0n1p3 on /var/home type btrfs (rw,relatime,seclabel,ssd,discard=async,space_cache=v2,subvolid=257,subvol=/home)

$ ls -ld /home
lrwxrwxrwx. 1 root root 8 Jan  1  1970 /home -> var/home

That is the theory behind my suggestion above. I was hesitant to go into the detail here because I have been blasted for doing so in the past.


What is needed:

- Your help to find out why Dropbox is not working on Fedora-based distro, Bazzite.