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.
