# Dropbox support

**URL:** <https://universal-blue.discourse.group/t/dropbox-support/10297>\
**Category:** Bazzite\
**Created:** [August 13, 2025, 4:19am UTC](https://universal-blue.discourse.group/t/dropbox-support/10297 "2025-08-13T04:19:58Z")\
**Posts on this page:** 1\
**Showing post:** 10

<div class="post-metadata">

**Author:** ![klmcw](https://avatars.discourse-cdn.com/v4/letter/k/eb8c5e/32.png) [@klmcw](https://universal-blue.discourse.group/u/klmcw)\
**Post date:** [August 25, 2025, 6:28pm UTC](https://universal-blue.discourse.group/t/dropbox-support/10297/10 "2025-08-25T18:28:21Z")

</div>

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

```auto
$ 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.

---

_[View the full topic](https://universal-blue.discourse.group/t/dropbox-support/10297)._
