This question has been asked several times, but the standard answer does not apply.

Current system: Ubuntu 18.04, kernel version 4.15.0-29-generic. But it started on - I think - 16.xx.

The system comes with this question at user login. A simple Cancel is fine for Dropbox to do the thing it is supposed to do. Occasionally it asks 3 times, somewhere in a login session.

The standard advice on the forum is to change the according line in /usr/bin/dropbox into PARENT_DIR = os.path.expanduser("~"), but that is already how it comes for the last few years. I install each release from scratch on alternating root partitions, so no left-overs. /home is on a separate partition, so that's a place for a possible left-over. The message has recently been absent for about 3 weeks, but after the latest kernel update it's back. Note that the system now asks for permission to execute /bin/sh, no longer for /usr/bin/dropbox.

Your help would be appreciated.

Tia, Theo

  • Maybe you have a desktop file in your startup applications with sudo sh in its Exec line? – steeldriver Aug 5 '18 at 13:29
  • find . -name "*.desktop" -exec grep sudo {} \; yields nothing. – tpg Aug 5 '18 at 20:25
  • Thanks for at least steering me in the right direction; I'm also getting that error on login sometimes and I couldn't figure out where it was coming from. I have dropbox installed also. Note that the actual current version of the binary is installed in ~/.dropbox-dist and gets auto-updated, so it could be something in there. The "absent for about 3 weeks" was likely due to the binary not being updated in that time. I'm betting it only happens when a new version is pulled in. – Tobias J Sep 21 '18 at 20:32
  • The same problem appeared for me today ok (K)Ubuntu 18.04. I log in and something asks me fot authentication. Googling yielded that it's caused by Dropbox. This is not because of what I have in startup applications - trying to exec "dropbox start -i" maually triggers the permission dialog as well. I have tried this solution: maketecheasier.com/fixing-authentication-issue-dropbox-ubuntu, but the PARENT_DIR is already set to "~". I have tried reinstalling Dropbox as well, but did not help as well. – Mitu Oct 18 '18 at 14:45

For some reason

chmod 755 ~/Dropbox

fixed the problem for me. I recall that I've recently moved my Dropbox folder from NTFS partition symlinked in my home folder to physically be in my home folder - and probably didn't set the permissions after it.

  • 755 did not work for me. The problem persists in Ubuntu 18.10. – tpg Oct 23 '18 at 14:10
  • For me neither. Also Ubuntu 18.10 – CPBL Jan 29 '19 at 18:23
  • It fixes the problem if it is only related to file permissions and not ownership. Also, it sets the execute bit in all files and read permissions to everyone, that you do not need and you may not want. Please check my answer for a more comprehensive solution. – jjchico Nov 15 '19 at 15:38

The right answer is you had some file in sync folder (through symlink maybe) which Dropbox had no access to.

  • Thanks. I am not aware of any symlink I created the past two years, except some documents I symlinked from Dropbox to local not too long ago, but way after the problem arose. I ran "ls -lR" in the Dropbox folder, and checked for any line starting with "l", and any line containing ">". No irregularities. Something else I should do? – tpg Apr 29 '19 at 20:32
  • 3
    It's not about symlinks, it's about permissions, try something like this: find <dropbox_folder> -not -user <your_username>. – WitcherGeralt Apr 30 '19 at 11:01
  • I have done so already long time ago, but it (still) yields nothing. Strangely the message does not show at each startup. Say 99% of the time. Occasionally 3 consecutive (!) times during a session. Can it be a timing issue during startup? – tpg May 4 '19 at 15:19

I think I finally solved the problem. In my case the message was generated by a temporary Dropbox script in /tmp that was tying to give universal access permissions to the files in my Dropbox. The problem was a file owned by root in my Dropbox tree that Dropbox could not update.

I solved the problem doing this (I assume $HOME/Dropbox y your Dropbox folder, which is the default. Change if appropriate).

1) As root, be sure you are the owner of all the files in your Dropbox:

$ sudo chown -R $USER $HOME/Dropbox

2) Give owner's read and write access to all files and directories in your Dropbox:

$ chmod -R u+rwX $HOME/Dropbox

Good luck.

  • Thanks for posting. However, these actions have been tried before and once more, but the problem persists. – tpg Nov 22 '19 at 13:29
  • This was the answer that worked for me - it was a single root-owned file copied into a dropbox dir that was causing the problem – bph Dec 10 '19 at 11:32

Watching the terminal when running "start dropbox", I see also the following advice:

Please run "echo fs.inotify.max_user_watches=100000 | sudo tee -a /etc/sysctl.conf; sudo sysctl -p" and restart Dropbox to fix the problem.

This solved the problem for me, without having to give Dropbox sudo powers to do whatever it wants.

  • I did as you advised, copy-pasted your text into a konsole. But alas. – tpg Feb 4 '19 at 12:28


If Dropbox finds files in its folder that aren't owned by your user, it will try to run a script with super user privileges to change the ownership of those files to your user.

If you click Cancel, Dropbox won't run the script but you'll continue to get the popup because it will continue to detect the problem.

If you're able to confirm it is Dropbox causing the popup, then the solution is to enter your credentials and let it run the script. More details below.


I just got this same popup, but not at login:

enter image description here

I expanded Details and then I searched the web for org.freedesktop.policykit.exec which pointed me to pkexec.

Looking through my processes for pkexec, I found:

$ ps -ef | grep [p]kexec
root     11040 26447  0 14:16 ?        00:00:00 pkexec /bin/sh /tmp/tmp5vgk_93m

So of course I was curious what that file was doing:

$ cat /tmp/tmp5vgk_93m
chown -h -R 1234 "/home/user/Dropbox"
chmod  -R u+rwX "/home/user/Dropbox"

It looks like Dropbox must have detected that there are some files in my Dropbox folder that aren't owned by my current user.

I used find to confirm:

$ find ~/Dropbox \! -uid 1234

Sure enough, looks like some of the files aren't owned by my user:

$ ls -l /home/user/Dropbox/Projects/picodrive/cpu/fame/famec.o
-rw-r--r-- 1 root root 1346564 Dec 18 13:33 /home/user/Dropbox/Projects/picodrive/cpu/fame/famec.o

In theory Dropbox shouldn't have any problem syncing that file since it's world-readable, but at least what they're doing makes sense.

I also noticed that while Dropbox was syncing I saw errors like this, which seems to be an additional confirmation:

Can't sync "famec.o" (access denied)

Last but not least, I'm going to put this here because I had trouble searching the web for this problem:

Authentication is needed to run `/bin/sh' as the super user


I had this problem a while back. To fix this problem, here are the steps I took. These commands were executed from a terminal CTRL+ALT+T

rm -R ~/.dropbox*
sudo apt purge -y dropbox
sudo apt install -y dropbox python3-gpg

Then you can start dropbox again. It will require you log back into your dropbox account, but after that it should work correctly without prompting you when it starts.

  • Thanks. I'll try at a convenient moment soon. – tpg Dec 12 '19 at 13:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.