Your workflow is unique 👨💻 - tell us how you use Dropbox here.
New installation of the desktop app on Fedora remains on Starting...
Application Affected Dropbox deamon for Linux System Operating System: Fedora Linux 43 KDE Plasma Version: 6.5.5 KDE Frameworks Version: 6.22.0 Qt Version: 6.10.1 Kernel Version: 6.18.7-200.fc43.x86_64 (64-bit) Graphics Platform: Wayland Processors: 24 × AMD Ryzen AI 9 HX 370 w/ Radeon 890M Memory: 32 GiB of RAM (30.6 GiB usable) Graphics Processor: AMD Radeon 890M Graphics Manufacturer: Framework Product Name: Laptop 16 (AMD Ryzen AI 300 Series) System Version: A9 Dropbox App Version dropbox-lnx.x86_64-241.4.4795 Issue Fresh install of dropbox on a new laptop running fedora 43 linux. It is "stuck" on "Starting..." I can't figure it out. Need help. If it matters I've been running dropbox on Linux for about a decade and have never experienced this issue. It is currently running just fine on my desktop PC, which is running fedora 42 Linux. I installed drop using the instructions on the dropbox site, using the Fedora 64 bit RPM. That was fine, and the usual files are installed in the places I usually see them. The deamon even properly set itself up to auto start - so when I reboot it starts up and puts itself in the tray (see screenshot). When I reboot it does ask me to sign in - bringing up the web browser, which asks me to 'Connect' my existing account. Which I do in the web browser. I get no complaints or errors. But it doesn't seem to have any effect on the deamon. When I look at the linked devices in my dropbox account the new laptop is listed there. So dropbox has made the association somewhere in it's databases. I have looked around in the linux firewall settings, but don't see anything relevant there. But then again I'm no expert in that regard. Permissions on the disks/files are under my user/group. I am the only user account on this system. I am not seeing any network issues on the system - all other network-using apps are running as expected. If anyone has ideas -- I'm all ears!
Ubuntu Plucky - Policy will reject signature within a year
warning: https://linux.dropbox.com/ubuntu/dists/plucky/Release.gpg: Policy will reject signature within a year, see --audit for details Control: https://linux.dropbox.com/ubuntu/dists/plucky/Release.gpg: Sub-process /usr/bin/sqv returned an error code (1), error message is: Signing key on 1C61A2656FB57B7E4DE0F4C1FC918B335044912E is not bound: No binding signature at time 2025-05-30T19:08:44Z because: Policy rejected non-revocation signature (PositiveCertification) requiring second pre-image resistance because: SHA1 is not considered secure since 2026-02-01T00:00:00Z -- Ubuntu Plucky is stable enough to support Dropbox, update signature PLEASE!!!!!! André
(Fedora 42) dnf update fails with 404 error
Application Affected linux client Device Fedora 42 qubes vm Operating System/Browser (if using the web) Fedora 42 Dropbox App Version (if using the app) nautilus-dropbox.x86_64 2025.05.20-1.fc42 @commandline Question or Issue dnf update is not working. It's giving me a 404 error from a dropbox url. As you can see in the error message, it is trying to download a fc43 rpm even though it is in a fedora 42 location, and even though I have fc42 installed. It confuses me why it would try to get a rpm for a different OS, and if that's what my problem is, I still have no idea how to fix it. Please help, my system software is 2 weeks out of date. ... >>> Status code: 404 for http://linux.dropbox.com/fedora/42/x86_64/nautilus-dropbox-2025.05.20-1.fc43.x86_64.rpm (IP: 127.0.0.1) - http://linux.dropbox.com/fedora/42/x86_64/nautilus-dropbox-2025.05.20-1.fc43.x86_64.rpm > >>> Status code: 404 for http://linux.dropbox.com/fedora/42/x86_64/nautilus-dropbox-2025.05.20-1.fc43.x86_64.rpm (IP: 127.0.0.1) - http://linux.dropbox.com/fedora/42/x86_64/nautilus-dropbox-2025.05.20-1.fc43.x86_64.rpm > >>> Status code: 404 for http://linux.dropbox.com/fedora/42/x86_64/nautilus-dropbox-2025.05.20-1.fc43.x86_64.rpm (IP: 127.0.0.1) - http://linux.dropbox.com/fedora/42/x86_64/nautilus-dropbox-2025.05.20-1.fc43.x86_64.rpm > >>> Status code: 404 for http://linux.dropbox.com/fedora/42/x86_64/nautilus-dropbox-2025.05.20-1.fc43.x86_64.rpm (IP: 127.0.0.1) - http://linux.dropbox.com/fedora/42/x86_64/nautilus-dropbox-2025.05.20-1.fc43.x86_64.rpm > >>> No more mirrors to try - All mirrors were already tried without success > ... >>> Interrupted > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------> [40/40] Total > Failed to download packages Librepo error: Cannot download x86_64/nautilus-dropbox-2025.05.20-1.fc43.x86_64.rpm: All mirrors were triedMake Dropbox compatible with Linux ARM processors
When I searched for this, I found this suggested several months ago for the purpose of Raspberry Pis. That suggestion was closed for inactivity. I had been using Dropbox in my Linux virtual machines on Mac with Intel processors for quite a long time. I just got my first Mac machine with Apple Silicon and was so disappointed this didn't work in the Linux VM on the ARM64. I depend on ability to share between the Virtual Machine and other devices connected to Dropbox for several of my workflows, and currently must use the Dropbox website to download, make my change, delete the online copy, then upload it again while in the Linux Virtual Machine. And hey, it sounds like adding this would help the Raspberry Pi folks too!
Dropbox installation causing persistent issues on Debian
Regarding an issues raised across several other posts: Like this one And this one Dropbox installations can result in persistent system issues on Debian 13. In an attempt to save others some headache, here's a few details I found helpful while attempting to fix the issue. Note that Debian isn't supported by Dropbox. Here is their list of supported distros (Ubuntu & Fedora). Regrettably, I believe that means no official support for this issue. Dropbox installation on Debian 13 can cause issues when uninstalling and/or updating. Common remedies for this kind of issue, especially those targeted at Debian amateurs (like myself) are generally inapplicable. Trixie changed some apt features. "add-apt-repository -r" no longer works. Don't go down a rabbit hole trying to get it onto your Trixie install, it isn't meant to be there. Typical methods to remove or purge Dropbox won't work. They result in errors, or are ineffective. The final entry in this guide got me the best results. Applied to the dropbox issue, that meant (ls -l /var/lib/dpkg/info | grep -i dropbox) followed by (sudo mv /var/lib/dpkg/info/dropbox.* /tmp). After this, I could get purge to correctly resolve. I hope that this saves somebody some time.Default Setting of Dropbox Automatically Syncing Everything Locally Destroyed My Linux System
Operating System Arch Linux Operating System and Dropbox Version are the latest. I installed a new Arch Linux OS yesterday, and today Dropbox completely destroyed it by its endless default auto-syncing feature. I have to reinstall the OS again. So basically, Dropbox has a default setting of downloading (syncing) every files automatically locally when installing. This is not the first time I have this kind of problem. Last time when I reinstalled my Windows 11 OS, I had to switch to another SSD because Dropbox insists I don't have enough space to download everything in the current one. After I installed Dropbox on the new Arch Linux system, it did not mention this issue like on Windows. It just silently keeps downloading everything without letting me know, since this has been a default option. And finally, every space I assigned to Arch Linux was occupied, the BTRFS partition collapsed after there was not any single available space left. I tried multiple methods to revive the operating system but failed. I lost every progress I made and had to start again to reinstall the system. I see that in the current Dropbox Windows UI there is an option of a preference of default syncing way. However, I am very sure that when installing it on Linux OS, there was not a notification or alert about this, and it was just kept defaultly to sync everything locally.
The Fedora repo config is currently broken
Application Affected Dropbox Linux app. Device HP Victus 16. Operating System/Browser (if using the web) Fedora Linux Workstation 43. Dropbox App Version (if using the app) Dropbox daemon version: 240.4.8493 Dropbox command-line interface version: 2026.01.15 Question or Issue I installed the latest rpm package and it also installed the Dropbox repository config. However, I'm getting this error when trying to update my packages: ``` Status code: 404 for http://linux.dropbox.com/fedora/43/repodata/835a786fe09e No more mirrors to try - All mirrors were already tried without success ``` I tried to change the release version to 42 and 41 and the update still didn't work after that. For now, I disabled the repo config to update without issues, but this is a temporary solution.Dropbox fails to start on Linux systems where /home is a symbolic link
Device Dell XPS 15 9520 Operating System/Browser (if using the web) Fedora 43 Kinoite Dropbox App Version (if using the app) v240.4.8493 Syncing Status Up to date (workaround exists) Question or Issue I noticed this issue after installing Dropbox via Flatpak, but I confirmed it exists on the headless official version, too. Fedora 43 Kinoite (and other atomic distros like Bazzite) keeps most of the root partition read-only, mounting a btrfs subvolume at `/home`, which is a symbolic link to `/var/home`. On my system, I see this: alex@alex-laptop:/var/home/alex$ echo $HOME /home/alex alex@alex-laptop:/var/home/alex$ grep $USER /etc/passwd alex:x:1000:1000:Alex Reinking:/home/alex:/bin/bash alex@alex-laptop:/var/home/alex$ grep home /etc/fstab UUID=b3440961-1f62-4818-a9c8-1b83b2c2c23f /home btrfs subvol=home,compress=zstd:1,x-systemd.device-timeout=0 0 0 After launching the Dropbox daemon, I am prompted to sign in. After doing so, Dropbox fails to create the ~/Dropbox directory, displaying the following error dialog: One way to work around this is to manually resolve the symbolic link: $ export HOME=$(realpath ~) $ ~/.dropbox-dist/dropboxd See more discussion here: https://github.com/flathub/com.dropbox.Client/issues/392 After doing this once, however, Dropbox is able to continue working; likely because the information in ~/.dropbox bypasses the broken file system check. Please fix Dropbox's file system support check!
I see no menu after clicking on the Dropbox tray icon on Fedora 43.
Application Affected Dropbox Tray Icon Device ThinkPad 230 Operating System/Browser (if using the web) Linux Fedora 43 Dropbox App Version (if using the app) Dear all, after losing many hours, I am getting nearer to make Dropbox work on Fedora 43 as it should. For now, I can see the Dropbox folder, the Dropbox tray icon on the top bar, however clicking on it (left/right click) does absolutely nothing. It means that it keeps synchronising all folders, which I don't want. I know that when installed correctly, the tray icon does show the sync menu, allowing to select which folders to sync and which not to. So obviously, I've gone wrong somewhere. Has anyone got a cure for this? I am not an expert, but have really found this very difficult.. All help is welcome. Thank you. Kind regards, Christos
