Need to see if your shared folder is taking up space on your dropbox 👨💻? Find out how to check here.
I created 2.4M files over the limit on the desktop app and now it's stuck syncing.
Application Affected Dropbox Device Dell OptiPlex 980 Operating System/Browser (if using the web) Ubuntu Linux Dropbox App Version (if using the app) v237.4.5655 Question or Issue I created 2.4M CSV files for a client, and the Dropbox app starting to upload these files. After almost 48 hours of this, I discovered that this was way too many files. My remediation was to exclude the top-levl directory from syncing. I made that change ten hours ago, but the app is still grinding away, doing something. I tried exporting the logs to find out what it might be doing, but the logs just show up as binary data -- I don't know how to read them. How can I sort this out?
OpenPGP signature verification failed with Debian Trixie.
Warning: OpenPGP signature verification failed: http://linux.dropbox.com/debian trixie Release: The following signatures were invalid: BADSIG FC918B335044912E Dropbox Automatic Signing Key <linux@dropbox.com> Error: The package repository 'http://linux.dropbox.com/debian trixie Release' is not signed. please add new key to: https://linux.dropboxstatic.com/debian/dists/trixie/
Moving the Dropbox folder on Linux Mint 22.2 using the Dropbox desktop app won't work
I've gone over to Linux Mint 22.2, have dropbox installed. I want to move it to my data drive...no problem. I made the move using the dropbox app, pointing it to my data drive. It did the sync fine, moved the files over, and all is good. Restart. Upon restart, I get this error message, and can't do anything about it. If I do a relink, it automatically installs the dropbox back on my OS drive and ignores everything it had just done prior the restart. How do I fix this without reinstalling it on my OS drive? Thank you.
Dropbox desktop app Linux Ubuntu failed to install.
Hi, I just received an email about the new desktop app so I downloaded it and tried to install it but the install fails with an error on libglib2. My system is a new install of Ubuntu Mate 24.04 with version 2.80.0-6ubuntu3.1 of glib2 which is >= 2.40Dropbox for Linux using up a lot of RAM
Application Affected Dropbox Device Lenovo Xiaoxin Mini PC Operating System/Browser (if using the web) Debian13 Dropbox App Version (if using the app) 237.3.5516 Question or Issue Within a few minutes of starting Dropbox, it consumes most of my machine's memory. My machine has a total of 32GB of RAM, and when it reaches about 25GB, the kernel's earlyoom is triggered, causing Dropbox to be killed. After I restart Dropbox, it is still killed within a few minutes, making it impossible for me to use it normally. I want to know if Dropbox has a feature to limit its own memory usage, or if there are any other solutions?
RAM memory usage goes through the roof
I'm using Ubuntu. Dropbix used to work fine on my system but recently something happened and when trying to sync files, the memory usage rapidly increases to max up 32 GB RAM, and then the system freezes and the Dropbox apps shut down. This happens when trying to upload a small file. What could lead to such a behavior?
Problems syncing on Bazzite with Linux.
Integration Affected Bazzite Linux, KDE and Gnome Desktops Device Custom PC Operating System/Browser (if using the web) Bazzite Linux, Kernel 6.15.9-116.bazzite Dropbox App Version (if using the app) 231.4.5570 Question or Issue -- I downloaded Dropbox as usual but it says the following when attempting to Sync: -- I've seen this happening only in Bazzite, I don't know if there are considerations given that is an inmutable distro and comes with btrfs filesystem by default. Which is weird because you supposedly support that filesystem. -- Also, other users in the Bazzite forums have tried the following: 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. -- Other user adds: 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. -- Another user has a theory but no action Plan: 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. / 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. What is needed: - Your help to find out why Dropbox is not working on Fedora-based distro, Bazzite.
