Join the Conversation: The Dash Community Is Now Open! ✨🎉
Linux
294 TopicsDropbox 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?25Views0likes3CommentsRAM 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?504Views3likes12CommentsOpenPGP 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/5KViews0likes15CommentsSame Dropbox folder and for multiple Linux distros, pointing to the same account.
Hello.... I have Kubuntu 24.04 and Fedora 42 KDE distro in my machine. Each have Dropbox installed. My question is: How to set a single Dropbox folder for those 2 distros with same Dropbox account? My goal is: To preserve storage space. Thank you in advance. [EDIT] Here are steps I have done: Install Dropbox on Kubuntu and setup Dropbox as usual. Dropbox folder set to /home/kubuntu/user/Dropbox. Then, move Dropbox folder to /home/dropbox.d/Dropbox. Install Dropbox on Fedora and setup Dropbox as usual. Dropbox folder set to /home/fedora/user/Dropbox. Delete folder /home/dropbox.d/Dropbox so Dropbox folder set to in step 3 can move to this folder. FYI: /home partition on Kubuntu and Fedora is the same physic partition. It's on /dev/sda12. I've tried these steps for editing file, adding new file, delete existing file. It seems no problem here. Do my steps are correct? Or, maybe there are another steps more powerful and efficient enough?Solved82Views0likes3CommentsProblems 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.Solved327Views0likes5CommentsDropbox says my environment doesn't support tray icon, by it does
In the following image you can see the dropbox system tray icon top right, with the error message below it. I am using the `i3wm` on Ubuntu with `i3status` to show the icons. To me this is a bug in the dropbox software failing to detect the presence of app indicator support correctlty, on argueabley the most common custom window manager.3.3KViews2likes32CommentsDropbox needs to update the required Fedora repository.
Apologies if this is the wrong place to post this. This is just a heads up that Fedora Linux was updated earlier this week to 42 and so the Dropbox Fedora repository is now producing error messages as it's still pointing to 41. The repository is at https://linux.dropbox.com/fedora.2KViews7likes39CommentsDebian Trixie - Policy will reject signature within a year, see --audit for details.
Warning: http://linux.dropbox.com/debian/dists/trixie/Release.gpg: Policy will reject signature within a year, see --audit for details Control: http://linux.dropbox.com/debian/dists/trixie/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:45Z because: Policy rejected non-revocation signature (PositiveCertification) requiring second pre-image resistance because: SHA1 is not considered secure since 2026-02-01T00:00:00Z277Views0likes1CommentDebian Trixie is expecting an InRelease file
Operating System Linux Debian 13 - Trixie Dropbox App Version v231.4.5770 I can see a Release file at Release file Debian is expecting an "InRelease" file as well as per this message when updating with apt: Error: Audit: Repositories should provide a clear-signed InRelease file, but none found at http://linux.dropbox.com/debian/dists/trixie/InRelease. It should be just a matter of adding the appropriate file in the same folder. This error is stopping the app to update properly.Solved183Views0likes4Comments