22

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.

Improve this question
4
  • Maybe you have a desktop file in your startup applications with sudo sh in its Exec line?
    – steeldriver
    Aug 5, 2018 at 13:29
  • find . -name "*.desktop" -exec grep sudo {} \; yields nothing.
    – tpg
    Aug 5, 2018 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, 2018 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.
    – Piotrek M.
    Oct 18, 2018 at 14:45

7 Answers 7

Reset to default
19

Solution

If Dropbox finds files in its directory 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.

  • The safest option is to change the permissions yourself (derived from Pablo Bianchi's answer):

    find ~/Dropbox/ ! -user $USER -exec sudo chown $USER:$USER "{}" \;

  • Alternatively, enter your credentials and let it run the script. This is only recommended if you can confirm Dropbox is creating the popup (more details below).

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.

Details

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.

(Unfortunately, I've only seen Details when using Xfce. I haven't seen it when running other desktop environments such as Gnome).

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
#!/bin/bash
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/ ! -user $USER
/home/user/Dropbox/Projects/picodrive/cpu/fame/famec.o
/home/user/Dropbox/Projects/picodrive/cpu/drc/cmn.o
/home/user/Dropbox/Projects/picodrive/cpu/cz80/cz80.o
...

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

Improve this answer
1
  • Tried this solution and quickly found, that my Dropbox directory contained some archives that were owned by root user, funny thing I was able to delete them without sudo. That strange window is gone now. Great job, thanks!
    – fires3as0n
    Jun 27, 2022 at 9:44
6

Dropbox may not be able to read the files for various reasons, like ownership, permission bits or broken links. I would assume you are using normal user.

  • Find files not owned by current user

    find ~/Dropbox/ ! -user $USER

  • Change ownership and group of those files

    find ~/Dropbox/ ! -user $USER -exec sudo chown $USER:$USER "{}" + –

  • Find files not readable with current user

    find ~/Dropbox/ ! -readable -ls # -delete to remove them

IMO, this is a security issue on Gnome.

Improve this answer
4

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.

Improve this answer
3
  • 755 did not work for me. The problem persists in Ubuntu 18.10.
    – tpg
    Oct 23, 2018 at 14:10
  • For me neither. Also Ubuntu 18.10
    – CPBL
    Jan 29, 2019 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, 2019 at 15:38
2

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

Improve this answer
3
  • 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, 2019 at 20:32
  • 4
    It's not about symlinks, it's about permissions, try something like this: find <dropbox_folder> -not -user <your_username>.
    – WitcherGeralt
    Apr 30, 2019 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, 2019 at 15:19
1

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
Improve this answer
2
  • Thanks for posting. However, these actions have been tried before and once more, but the problem persists.
    – tpg
    Nov 22, 2019 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, 2019 at 11:32
1

Watching the terminal when running "dropbox start", 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.

Improve this answer
2
  • I did as you advised, copy-pasted your text into a konsole. But alas.
    – tpg
    Feb 4, 2019 at 12:28
  • 1
    I believe they meant "dropbox start"
    – Mtl Dev
    Mar 22 at 18:07
0

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.

Improve this answer
1
  • Thanks. I'll try at a convenient moment soon.
    – tpg
    Dec 12, 2019 at 13:27

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .