From ArchWiki

Hack To Stop Auto-Update

I have concerns about this section of the article mainly because I just installed Dropbox from the AUR and I have no .dropbox-dist directory (I have seen it in the past however). I am wondering if this is something that has changed in a more recent version of Dropbox and perhaps this directory no longer applies and renders this section of the Archi Wiki entry out of date for the moment. Taliesin (talk) 01:52, 26 August 2014 (UTC)

Wait until the auto-update kicks in. The auto-updater assumes that the ~/.dropbox-dist/ directory is the installation path (and when using the upstream installer instead of AUR, it indeed is), so it just extracts the downloaded tarball into this path. For the record, the AUR package uses /opt/dropbox/ as the installation path. -- Lahwaacz (talk) 07:02, 26 August 2014 (UTC)

This hack saved my rear end a couple of weeks ago when Dropbox 3 was pushed (with regressions). The only other place that seemed to hint at that trick was on Dropbox's old forum, which as far as I know was deleted. So, I just wanted to say thanks for documenting the undocumented feature. KlipperKyle (talk) 05:46, 30 December 2014 (UTC)

I've posted a permanent solution for auto update to work with dropbox in aur (, essentially informing systemd that the dropbox service is a forking service, that will need to use PIDFile for working properly. Also adding an exception for SIGKILL so it knows that its legal for it to kill its forked processes. This way auto-update works properly again. Hopefully it will get integrated. Soderstrom (talk) 15:19, 1 September 2018 (UTC)

Run as a daemon with systemd user

The configs in section "Run as a daemon with systemd user" do not work for me. Getting an "Failed to get D-Bus connection: Verbindungsaufbau abgelehnt" error when executing "sudo systemctl --user start dropbox@:0.service". Configs of section "Run as a daemon with systemd user" do work however. Bkk (talk) 10:10, 12 February 2015 (UTC)

I have Dropbox successfully running using systemd user with a system tray icon. I updated that section with the steps I used to get it working
Silverhammermba (talk) 20:59, 15 February 2015 (UTC)
Thanks for your help! Unfortunately the changes do not work for me ("start request repeated too quickly for dropbox.service" even though I waited quite some time):
Feb 15 23:01:43 bkk-V5 systemd[731]: Starting Dropbox...
Feb 15 23:01:43 bkk-V5 systemd[731]: start request repeated too quickly for dropbox.service
Feb 15 23:01:43 bkk-V5 systemd[731]: Failed to start Dropbox.
Feb 15 23:01:43 bkk-V5 systemd[731]: Unit dropbox.service entered failed state.
Feb 15 23:01:43 bkk-V5 systemd[731]: dropbox.service failed.
So far, only starting dropbox via terminal "dropbox" does work for me. --Bkk (talk) 22:08, 15 February 2015 (UTC)
The dropbox service is configured to restart when it fails, but it looks like it's always failing for you so it gets into a loop. What does journalctl --user --unit=dropbox.service say? Or systemctl --user status dropbox? Can you run other user services successfully?
Silverhammermba (talk) 01:38, 16 February 2015 (UTC)

Right click does not show the menu

If right clicking the dropbox icon does not show the menu as it should, or shows the applet menu (Cinnamon, maybe others) try ending Dropbox and running it with: dbus-launch dropbox

Koassim (talk) 10:49, 18 March 2016 (UTC)

Is this another symptom of user buses? -- Alad (talk) 11:45, 18 March 2016 (UTC)
Maybe? I don't know. Sorry. Koassim (talk) 18:07, 19 March 2016 (UTC)

The part about networkmanager does not apply anymore

The networkmanager scripts are not available on the AUR anymore, so I guess the functionality has been included elsewhere? Anyone knows that?

—This unsigned comment is by OdinEidolon (talk) 17:15, 10 April 2016‎. Please sign your posts with ~~~~!

Alternative for KDE

The latest dolphin already have working services for dropbox, maybe it should be noted somewhere in the article as an alternative to an external client? Bugmenot2 (talk) 23:49, 11 April 2016 (UTC)

Securing your Dropbox

Here it's written that data on Dropbox servers are stored not encrypted, therefore the possible need to setup a way of encrypting sensible data. Is it still true? Because if you head to the Dropbox Help Center, under Security and privacy it's stated that:

- Dropbox files at rest are encrypted using 256-bit Advanced Encryption Standard (AES)

and, as already written in the wiki page,

- Dropbox uses Secure Sockets Layer (SSL)/Transport Layer Security (TLS) to protect data in transit between Dropbox apps and our servers; it's designed to create a secure tunnel protected by 128-bit or higher Advanced Encryption Standard (AES) encryption.

Source: [1]

If the point here is to provide a way to encrypt data locally in a Dropbox folder, than it's okay, but maybe the line regarding Dropbox security should be corrected.

--Eb90 (talk) 11:50, 5 April 2017 (UTC) eb90

Yes, technically the files are encrypted at rest, but Dropbox has the key to decrypt them. When you log in to your Dropbox account through your web browser, you have access to the decrypted files. Their encryption does not protect users from their account getting phished, someone guessing their login credentials, or Dropbox itself being comprimised. Changing this section might decieve users into believing that it's unnecessary to take their security into their own hands.

--cryptodoomchicken (talk) 14:47, 5 April 2017 (UTC)

dropbox-cli and configuration

The package dropbox-cli, while mentioned on the page does not get any discussion. One big advantage of the cli is that you can configure dropbox via the command line on a headless system. Very useful, and seems worth mentioning. Docs for the cli are here: (have to scroll down a bit) or you can get them from the cli itself.

Dansteen (talk) 18:12, 21 July 2019 (UTC)

Alternative clients

Should there be a section about alternative clients? For instance, the official client does not support ARM64, but eg [Maestral]( is in AUR, and works pretty well on that system.

Grav (talk) 07:17, 2 September 2022 (UTC)