Dropbox support

Bazzite
1

I looked up that Dropbox supposedly supports btrfs filesystem, but an error pops up that the filesystem is not supported, that I should change to ext4. Any workarounds or official stance on the support for btrfs?

2

Iā€™m using Dropbox (from flatpak) on a system with btrfs. I didnā€™t have any problem or any popup with errors or telling Iā€™m using an unsuportted fs.

3

FYI - that a common issue that people run into with these kinds of integrations is that the tools tend to offer /home/userid as part of the default mount location. Many have resolved their issue by changing the mount path to begin with /var/home/userid instead.

@brogos do you remember if you had to use the flatseal app to change the perms of the dropbox flatpak to have access to your HOME directory? Or was that already set?

But to be honest the error message described does not sound like a perms issue.

image

4

Retargeting to /var/home worked on my last install and is still working on my desktop, but I finally got around to installing on my laptop and the problem I am finding is that the dialog that should pop up to let me move the target folder ā€¦ just doesnā€™t appear?

I get the usual ā€œfilesystem not supportedā€ and the popup with the three buttons, but clicking the move button does nothing, nor does the option in the preferences dialog. Iā€™m not sure if somethingā€™s missing or if itā€™s just broken; I noticed the preferences window has changed for the worst too.

5

I just installed it with flatpak, launched it and logged. Nothing more.

1 Like
6

Iā€™m seeing the exact same thing. Weirdly I had this working on my computer a week ago, but now on my wifeā€™s computer it refuses to work. Wonā€™t launch after clicking the move button.

@klmcw the flatseal app shows that dropbox has the permissions for home by default.

7

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.

1 Like
9

Any steps I can follow to do that?

10

I do apologize that I can only offer theory behind the suggestion. The reason is that I do not use Bazzite and I am aware there are differences.

And, I have not used Drop Box myself for over 10 years. So I would not be able to test any theories I might come up with.

But I am convinced that it has something to do with / being of fs type composefs; which the Drop Box flatpak does not recognize.

Oh and did you notice the date on the symlink /home (repeated below)? composefs is not a full featured filesystem. It was introduced as a workaround to a serious defect in btrfs. It is that same defect why we all (users of Universal Blue offerings):

  • are stuck on an old kernel version
  • will be moving away from btrfs some time this year
$ ls -ld /home
lrwxrwxrwx. 1 root root 8 Jan  1  1970 /home -> var/home

This is an observable symptom of at least part of the problem.

So at a higher level - my suggestion was to configure the Drop Box flatpak to use /var/home (whose fs type it DOES understand) instead of /home (whose fs type it does not understand).

I hope that makes sense.

1 Like
11

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 (and @mitocondria ā€˜s side).

In any case, thanks for the help! You were on the forums when Linux was released, I was born the day Linux was released :smiley: , been using it since I was pretty dang young as well.

2 Likes
12

To be clear, the Move button is an error message from Dropbox.

clipboard_2025-08-25_09-42
clipboard_2025-08-25_09-42616Ɨ232 10.8 KB

1 Like
13

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.

14

Thanks for the help. Iā€™m talking with the Dropbox support team right now and your comments hopefully will help get this resolved. :heart:

1 Like
15

If you donā€™t get the Flatpak working, I typically use rclone for this. Once you set it up, you can mount it like:

rclone mount --vfs-cache-mode full dropbox: /var/home/$USER/Dropbox/

It will be visible in Dolphin. If you want this to be wife-friendly, probably setting up a systemd service that mounts it when logging in should work.

2 Likes
16

Forgive me if this is considered off-topic, but I had been considering dropping Dropbox anyway; so if anyone can point in the direction of a substitute that behaves more nicely, I would consider this a potential solution. I fiddled with SyncThing a bit but itā€™s not really suitable for my usecase.

17

@annarcana , a lot of people rely on NextCloud to host their own cloud storage solution. It can be relatively easily started in a container on your LAN if you are good with the limitation of only sync-ing when connecting to your LAN. That is the most secure way.

Alternatively, there are cloud hosting providers that support NextCloud. That would probably be the next best option if you are willing to spend a little money. I assume you would be ok with the security down sides of that (your files are outside of your LAN) because you are already using DropBox.

Finally, and I do not recommend this, but it is an option, you could host it in your LAN and poke a hole in your firewall. Very dangerous unless you have skills as a network engineer.

I, personally, use a NAS and rely on rsync. I have an app on my phone to intentionally pull files when I need them. There are only 2 files I sync. That number is kept low on purpose.

For my use case that is the simplest and most secure approach. Your use case is probably different.

Just a couple of ideas ā€¦ there are probably many othersā€¦

1 Like
18

I ( a fellow greybeard ) got it working based on suggestions by you klmcw - I used flatseal to:

1 - Add ā€˜/var/home/{myuser}ā€™ to the allowed directories under ā€˜Other Filesā€™

2 - Under ā€˜Environment, variablesā€™ I added ā€˜HOME=/var/home/{myuser}ā€™

Replacing {myuser} with my actual user name of course.

It started up - I had to login to dropbox on the website to connect yet again, but now itā€™s churning away downloading my files.

6 Likes
19

This worked for me. A lot of other places I looked for answers only mention the first edit, but the second.

1 Like
20

@merlinblack instructions worked for me.
Thanks to them and @klmcw

1 Like
21

@merlinblack thanks for taking the time to document your solution!

FYI - I have an app I have written in python that uses sqlite db files for storage. I ran into a similar problem with the ā€˜DB Browser for SQLiteā€™ flatpak app.

When it loads data into the db, the first thing my app does is discover the dir that has the latest CSV files to load and creates a symlink local to the app with a predictable name (ā€˜.files/input/ā€™). It then creates a symlink to the dir for the sqlite files (ā€˜.files/db/ā€™).

I had used /home/klmcw/Documents/ā€¦ as the prefix for the source dir of these symlinks. The flatpak would not open any of the sqlite files in `.files/db/data.db` because of it.

I modified the configuration to use /var/home/klmcw/Documents/ā€¦ instead when creating the symlink and voila - it opened them just fine.

I am sharing this to point out that the solution may not always involve using flatseal. But the root cause for all the ones I have encountered does involve the /home symlink.