nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Dropbox client asks to reconnect on every fresh boot (corruptdball error on Linux)

hillard28

Since August 31, 2026, when logging in after a fresh boot the Dropbox client asks me to connect my account before it can begin syncing.

From what I can tell, the client starts normally, but about 20 seconds later it relaunches itself as /opt/dropbox/dropbox /corruptdball, recreates ~/.dropbox/instance_db/hostkeys, ~/.dropbox/instance1/hostkeys and config.dbx, and shows the sign-in window. Restarting the client or logging out and back in do not trigger the issue. It's almost as if the client is flagging a database issue when accessing its own key files.

I've tested wiping ~/.dropbox and ~/Dropbox/.dropbox.cache, as well as a full reinstall. I've also tested blocking auto-updates and forcing only one client version. My /etc/machine-id and hostname are stable across boots, and no shutdown issues as far as I can tell.

I'm on Arch Linux 7.2.4 using Dropbox 264.4.3421 (but also tested 266.4.3911 and 268.4.4124). My home folder is on btrfs. I believe the issue began to occur around when I upgraded from kernel 7.1.11 to 7.2.2.

Find more posts tagged with

Desktop

Error Messages

Linux

Accepted answers

All comments

Jay

Hi @hillard28, thanks for bringing this to our attention.

Just for confirmation, is your Dropbox folder located on an internal drive or external drive connected to your machine?

If you can share any other error messages or logs, that'll help me narrow this down much faster.

hillard28

Hi Jay,

My Dropbox folder is located on an internal drive using the default location (/home/<username>/Dropbox). I'm attaching a zipfile of my ~/.dropbox/logs folder from this morning, which I believe should capture at least one of the failures.

[Removed as per Community Guidelines]

Jay

Thanks for the logs, unfortunately they were unreadable on our end, so I've removed them for security and privacy purposes.

At this point it might be better for the support team to look into this in more detail. You can contact them directly via this link, and they'll be able to investigate further.

hillard28

Ah, sorry about that. Thank you for removing.

Jay

No worries, it was more of a precaution just in case.

When you contact the support team, you should get a ticket ID which is sent via email a few minutes after your chat ends. Please let me know the number here so I can locate it in our system.

hillard28

Actually, I believe I created one this morning after speaking with the support bot, though I haven't spoken to anyone yet. The ID is 26662235.

hillard28

I performed strace runs of Dropbox both immediately after rebooting (when the problem occurs) and after restarting Dropbox (when it doesn't), and might have narrowed the cause down to a change in btrfs behavior between 7.1 and 7.2.

With Linux 7.2 (commit c2a74ed0494c), btrfs's statfs() filesystem ID includes the partition's device number, which changes between boots on systems with multiple drives. The Dropbox client appears to derive its local key from that ID, so it then can't decrypt its own files after those reboots.

This might also explain why this issue only occurs on one of my systems, which has a dual boot configuration (each using one drive), whereas the other system with a single drive does not. I don't think the partition device numbers changing across boots is new to 7.2, but I believe btrfs incorporating them into the filesystem ID is.

I can share the logs from those two strace Dropbox runs, if it would be helpful.

vankyan

I am experiencing the same problem on Fedora 44 KDE. On each fresh boot, Dropbox is signed out and it requires removing duplicate sessions from other machines in order to add again this machine that was active and signed in before the reboot. In other words, Dropbox is currently largely unusable and unreliable on Linux.

hillard28

Hey @vankyan, for my own troubleshooting, do you mind confirming some basic details about your setup? Are you on Linux kernel 7.2 and is that when your issues started? Are you using btrfs and do you have a multi-drive/disk setup?

vankyan

Hi @hillard28 , I believe it started with kernel 7.1.8. I am now on 7.2 and it continues. I use btrfs but I have a single drive on both machines.

hillard28

I can confirm that a wrapper around Dropbox via LD_PRELOAD which replicates the pre-7.2 btrfs ID reporting solves the issue. So at least in my case this does appear to be related to changes in btrfs behavior.

anmarui74

# Dropbox Community post (to publish)

**Category:** Dropbox Desktop App / Linux

**Title:** Linux client asks to re-link after every reboot (device still shows as connected)

**Body:**

Hi,

I'm running the official Dropbox Linux client (standalone, **270.4.3312**) on **CachyOS**
(Arch-based, kernel 7.2.5). Since a while ago, the client **loses the account link after every
reboot**: on each start it prints

```
To link this computer to a Dropbox account, visit:
https://www.dropbox.com/cli_link_nonce?nonce=...
```

and I have to link it again. Interestingly, the computer **still appears as a connected device**
in https://www.dropbox.com/account/security, so the link is lost only on the client side.

Things I've noticed / already tried:
- The daemon process starts with the recovery flag:
  `~/.dropbox-dist/dropbox-lnx.x86_64-270.4.3312/dropbox /corruptdball`
- `~/.dropbox/host.db` is missing when it asks to link, and `unlink.db` is (re)created at startup.
- `PRAGMA integrity_check` on `~/.dropbox/apex.sqlite3` returns **ok** (no real DB corruption).
- Filesystem: `/home` is **Btrfs** (`@home` subvolume, `compress=zstd`). `btrfs device stats`
  shows 0 errors and a scrub found no problems.
- System clock/RTC is correct (NTP synced at boot).
- I did a **full clean reinstall** (fresh `~/.dropbox`, fresh `~/.dropbox-dist` downloaded from
  dropbox.com) and re-linked — the problem persists after a reboot.
- Running the daemon from a **systemd user service** (start at login). Only one instance runs.
- Made `~/.dropbox-dist` **read-only** (ArchWiki "Prevent automatic updates" workaround) — no change.
- Consolidated the SQLite WAL before start (`PRAGMA wal_checkpoint(TRUNCATE)`) — no change.

Is this a known issue with the standalone Linux client on Arch/Btrfs? Is there any server-side
reason the device might be getting unlinked on client restart? Any pointer would help.

Thanks!

Megan

Hey there, @anmarui74, thanks for posting here!

Since the OP also reported a similar concern, I went ahead and merged your post under a similar thread.

I checked the support ticket our user @hillard28 had with our specialized agents for some more insight regarding this case and I'd like to share what they mentioned.

"I'd like to also quickly mention that the reason you may have encountered this error is due to Arch Linux not being technically fully supported by our engineering team, due to it being on a rolling update cadence. Here's more information about our supported builds below: https://help.dropbox.com/installs/dropbox-desktop-app-for-linux#Supported-Linux-distributions
Lastly if this function was working properly in previous versions of kernel I would recommend rolling back the OS version, as a potential solution."

Since you're on a similar configuration, I believe this might be useful. If you have any questions, let me know!

Здравко

Hi @Megan,

I won't comment the main issue of this thread, but want to comment what you posted (or rather what your "specialized agents" had posted).

In the referred help topic (that's linked to) is no any limitation of the kernel version in use (there are other mistakes in advices that, if followed literally, may lead to crash in some systems in particular cases, but it's different story). Most important is statement that supported are Ubuntu distributions 18.04 or later and Fedora distributions 28 or later! I especially underlined "OR LATER"! And, at the same time the "solution" is rolling back the previous kernel version.

Let's take a look on your supported Fedora distributions for instance. When take a look on Dropbox supported Fedora distributions we may see that one of the versions there is Fedora 45 for instance.

Now, let's take a look on available kernel version in Fedora 45 that's in use. Something visible here: https://packages.fedoraproject.org/pkgs/kernel/kernel/fedora-45.html

Oh… is there some mistake?! Does that mean Fedora 45 is NOT supported (the same about Ubuntu)? Megan, please, forward this to the agents that posted what you forwarded here. They are more "qualified" and may decide what that means.

In this context one question of me: Does that mean the real Linux support is in process of complete stop? 🧐 (no even a partial like currently)

hillard28

I think that’s purely precautionary advice, since the reality is Arch isn’t officially supported. I’ve already explained what I think is the cause (based on how I was able to resolve) and that I believe it’s kernel-related (I actually used the Fedora example as well) to support, so hopefully a fix comes out soon.