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.

Pablo Bianchi
  • 15,657
tpg
  • 329
  • 2
  • 5
  • Maybe you have a desktop file in your startup applications with sudo sh in its Exec line? – steeldriver Aug 05 '18 at 13:29
  • find . -name "*.desktop" -exec grep sudo {} ; yields nothing. – tpg Aug 05 '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: https://www.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 '18 at 14:45

7 Answers7

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

bmaupin
  • 4,930
  • 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 '22 at 09: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.

Pablo Bianchi
  • 15,657
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.

  • 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
2

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
  • 4
    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 04 '19 at 15:19
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.

Mtl Dev
  • 175
CPBL
  • 788
  • 1
  • 9
  • 21
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
    
Pablo Bianchi
  • 15,657
jjchico
  • 179
  • 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
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.

schworak
  • 871