Dropbox support

[FJ44404]

It’s good to hear there is a way to get the Flatpak working!

I was setting up dropbox a few months ago and ended up using a distrobox based on Fedora:42 to get it running.

Just wanted to drop by and say that is another alternative, though the flatpak is likely less fiddly.

[andrei_chiffa]

Thanks - did it for me! I believe you do, however, need to also add the trash directory as well so that the files can be deleted from Dropbox partition, but you will see a red complaint box on the top.

[Dude]

thanks so much for sharing this tip!

I was about to give up getting Dropbox working on Bazzite

your solution worked like a charm!

[Danathar]

@klmcw

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.

WARNING: this explanation assumes some level of experience with Linux filesystem types.

• / 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.

And with that in mind:

DISCLAIMER: If you are an overly sensitive person - please ignore everything in this post. It was not intended for you.

But, I truly do hope my explanation helps. While I do not use Bazzite, I do use Bluefin-dx - I feel the pain, too, of the introduction of the composefs type for / by upstream. But composefs has worked around a serious problem that is leading to Universal Blue switching fs types in the near future - i.e., some of us (might turn out to be distro specific) will be moving to XFS soon-ish.

Who Am I?

I am just a gray beard who has been using *NIX since long before Linux even existed. I was following the usenix news group where Linus Torvalds announced his very early work that led to the Linux kernel. He was still a university student in Helsinki at the time.

We were all learning about Linux back then, too. I can relate.

The discussion among the development is mainly moving to XFS as the default for the LTS version of Bluefin. There have been some discussions about making XFS the default in the installer for Bluefin non LTS, but it’s unclear to me what the decision was on that. Regardless, as I understand it BTRFS will still be there as an option for people who want compression and snapshots and an actual copy on write file system which XFS is not.

uCore is Xfs Default but that’s because you actually install using fedora core OS and then you re-base to uCore. In that case, you would actually decide which file system you want to use in your ignition (though if you do nothing it’s xfs)

[klmcw]

Thanks. I am familiar with all of that. My understanding is that stable will continue to track Silverlight for now - i.e., continue to use btrfs.

I did have an opportunity to comment yesterday on the design improvement progress in the underlying issue for composefs/erofs. It may take awhile to see the result of the discussion there.

Mainstream DEs need to be taught to ignore filesize on composefs.

Because I use Silverlight as well, I will continue to try to stay informed. They are so close. But I think they are trying to do too much with composefs from an architectural layering perspective. And it is a complex problem with a few competing requirement sets; I just need to be patient while they work through the design.

[inffy]

Those plans were scrapped, atleast in Aurora/bluefin for now.

Silverblue/Kinoite never had such plans as they adhere to the core fedora usage.

[gerarderloper]

cheers this seemed to work.