Has anyone been using dropbox successfully lately? If so, I’d appreciate help. I’m seeing two current options, neither of which appears to work. Either you set up your own service, as described here or you use home manager’s services.dropbox.enable. In both cases, the service does not appear to start automatically, even after a restart, but maybe that’s because I’m not logged in. When I start dropbox manually, it takes me to the web to login, where I see the message:
In fact, the dropbox-cli version appears quite old, 2020.03.04, which is surprising with Nix, though I’m uncertain whether it’s talking about this or the dropbox daemon.
Does anyone have any thoughts on this. Any help would be much appreciated.
I am currently using the dropbox package without issues. I installed it yesterday, with system.stateVersion = "23.05";, using environment.systemPackages in the main configuration.nix file (not using home manager or others).
I indeed saw the error you mentioned the first time. But also I saw the Dropbox tray icon in the tray bar (using KDE Plasma), and after I clicked in its context menu and on “Sign in”, it opened another browser tab and I was able to login. After that I didn’t have any issues, it synchronized and working well.
Thanks for the response. I was able to get logged in, but when I didn’t explicitly create a service, I had to start dropbox manually before it appeared on my system tray, and even then it shut off after a few seconds. I went back to the approach described on the wiki, where you set up a custom systemd user service, and it kept my login info and appears to be working now.
At this point, the only issue is that the download speed is pretty ridiculous–currently 50 KB/s, and it was slower for a while. I’m not sure what that’s about, but I may have seen something similar when I tried dropbox on another linux distro.
In fact, the dropbox-cli version appears quite old, 2020.03.04, which is surprising with Nix, though I’m uncertain whether it’s talking about this or the dropbox daemon.
That is still the latest tagged release of nautilus-dropbox, which dropbox-cli is part of.
There are some newer changes, some of which we are cherry-picking.
But most of the code is actually in dropbox package, used by nautilus-dropbox, and that has not been updated in a while either.
Maestral uses the public Dropbox API which, unlike the official client, does not support transferring only those parts of a file which changed (“binary diff”). Maestral may therefore use more bandwidth that the official client. However, it will avoid uploading or downloading a file if it already exists with the same content locally or in the cloud.
I tried overriding the package locally to use version 2022.12.05 but that didn’t help. I did do away with the “you’re using a too old version of dropbox” message and I was able to log in. But the daemon would still not start.
I also tried just using the system version (without home-manager) as describe in the wiki but that didn’t work either.
I eventually just tried installing the dropbox-cli package in configuration.nix and manually trying to start it in the terminal. I appears to start (the icon shows in the tray and it appears to be syncing) but then it randomly quits without any useful error message (after a few seconds - a minute). It just says:
“dropbox daemo is not installed”. Which is bs because it initially installed it.
I’d really appreciate some help here if anyone has been able to solve this. Right now I’m debating with myself to just run it in a docker container but I don’t want to loose my file manager integration (nautilus).
@Mic92 Please don’t take this the wrong way but this is offtopic. I see this happen a lot in almost every issue (either on home-manager or on nixpkgs) where folks suggest maestral instead of dropbox. This is about getting the official client working and not using a third party package (which has it’s own of limitations and problems). Again, I’m sure you mean well but it rubs me the wrong way (kind of like the IRC comments back in the day: “just use this entirely other thing that you didn’t ask for”). (Again I’m sure that’s not what you meant).
I currently do have dropbox working, using the code given on the wiki: Dropbox - NixOS Wiki
When I tried other approaches (e.g., installing the dropbox daemon directly), the dropbox service had to be started manually and then shut down after a few seconds.
I think I got around the version warning by logging into dropbox in my web browser first, before installing the app. Beyond that, I’m not sure whether I did anything else. It just seemed like things suddenly started working, so not a very satisfying experience.
That’s interesting… I tried that approach I get the same behavior as when starting it from the terminal. It just keeps restarting after running for a few seconds.
@misterdrgn This just got worse. After my previous message I observed the journal showing the service crash once or twice (just like it did in the terminal) but has since been stable. Everything synced and appears to be working. I don’t know if I should be relieved or feel worse about it because I don’t know why it works.
Things I did:
Made sure to log in via the browser before starting anything (as per your suggestions)
Ran “dropbox start -i” (so it installs the daemon in ~/.dropbox-dist). I waited for it to download stuff but then it (predictably) failed with “no module gi”.
Then I started the systemd user service. I observed it fail once or twice but then it continued working.
The service I’m using from the wiki doesn’t differ much from the home-manager module so I’m going to take a look into it a bit more to see if I can get it working properly.
According to ‘top’, dropbox uses 650mb of ram, even when everything’s synced and I haven’t touched the dropbox directory in ages. Seems kinda ridiculous. I might look into that opensource alternative at some point.
But on NixOS it used to crash sometimes after a longer computer suspend, a manual restart was needed. Probably a systemd service would be enough to work around this.
I’m in the same situation of @deni; tried maestral, but I found it rather slow and it would produce lots of conflicting copies of my files (although I really cannot see how they are conflicting), so it’s very annoying. I’d rather not use dropbox than having all these conflicts to manage:
I’d also like to try using the dropbox daemon inside a (podman) container: I don’t care much about nautilus integration at the moment, so it should be feasible. Doing something incredibly naive would be to just mount the entire directory with something like this
podman run --userns keep-id -it -v "$HOME:$HOME" docker.io/ubuntu:22.04 bash
and provided all the necessary tools and libraries are installed, it should be possible to download the daemon and start it in the container. I know some libraries will be missing though so I might just create an image for that.
Alternatively create your own user-level systemd service unit with systemd edit --user --full --force dropboxd-podman.service and systemd enable --user dropboxd-podman.service.
Maestral works perfectly here. There’s a Maestral GUI package too. It autostarts fine on Gnome (added to startup apps in Gnome Tweaks). The only downside is that there’s no panel applet, so you can’t tell what it’s doing - although you do get notifications every time something changes elsewhere. On the plus side, the api token it uses doesn’t count towards one of your Dropbox devices, which is really useful if you’re on the free plan.
| 
(Again I’m sure that’s not what you meant).