You might see that the Dropbox Community team have been busy working on some major updates to the Community itself! So, here is some info on what’s changed, what’s staying the same and what you can expect from the Dropbox Community overall.
Forum Discussion
Need to "download proprietary daemon" every time Ubuntu restart.
I have installed Dropbox successfully on Ubuntu 14.04 using the 64-bit .deb installer from from https://www.dropbox.com/install-linux
Everything goes well and dropbox has synced all my files proper...
Sorry to hear about this Vicon!
First off, are you meeting all of our minimum requirements as per this page?
More specifically, Dropbox needs the following software to work on desktop environments:
- Glibc 2.19 or higher
- GTK 2.24 or higher
- Glib 2.40 or higher
- Libappindicator 12.10 or higher
- Nautilus 3.10.1 or higher
Having said that and as I'd really like to help with this, would you mind trying an advanced reinstall using this installer to see if this will fix your problem? In the meantime, you may also want to review this Help Center article too.
Keep me posted on your findings!
Walter
Dropbox Staff
Dropbox StaffSorry to hear about this Vicon!
First off, are you meeting all of our minimum requirements as per this page?
More specifically, Dropbox needs the following software to work on desktop environments:
- Glibc 2.19 or higher
- GTK 2.24 or higher
- Glib 2.40 or higher
- Libappindicator 12.10 or higher
- Nautilus 3.10.1 or higher
Having said that and as I'd really like to help with this, would you mind trying an advanced reinstall using this installer to see if this will fix your problem? In the meantime, you may also want to review this Help Center article too.
Keep me posted on your findings!
This is happening to me very frequently now, on multiple computers running linux mint 19. I have followed the instructions noted in this thread multiple times as well- it fixes the issue for a few days, but then like bad magic its starts doing it again.
I noticed that in the dropbox.desktop file,located in /home/[username]/.config/autostart, that the startup command includes the "-i" option:
[Desktop Entry]
Name=Dropbox
GenericName=File Synchronizer
Comment=Sync your files across computers and to the web
Exec=dropbox start -i
Terminal=false
Type=Application
Icon=dropbox
Categories=Network;FileTransfer;
Keywords=file;synchronization;sharing;collaboration;cloud;storage;backup;
StartupNotify=false
The -i option "auto installs dropboxd if not available on the system". Could this switch be malfunctioning, erroneously thinking that the daemon is not there, and be part of the cause of this issue? I'm not sure why the -i option is needed after dropbox has been installed anyway, but maybe it is needed for some reason.
The other thing to note is that whenever I get this installation pop-up prompt, dropbox is actually already running and the icon is showing in my tray. So regardless of whether I get this installation prompt or not, dropbox always starts up anyway and is already running, apparently in parallel to, and independent of, whatever check is being made that results in the prompt to re-install the sw. If I accept the prompt to re-download the sw, it does so and then invokes a second instance of dropbox and they both run side by side, with two icons in the tray. I can use dropbox with both instances, or a i can kill off one of the instances and continue. Very strange. I never let more than one instance run very long if I notice it because I doubt that is a good thing to let persist very long.
So anyway the guidance in this thread sort of worked for me temporarily but it consistently does not keep the issue from reoccurring so I'm just looking for ideas on what to try.
BNPNBXTR you were right!
The solution you proposed is almost perfect. I wrote almost because you need to do more one step.
Your temporary solution was remove "-i" from red line ("Exec = dropbox start -i" to "Exec = dropbox start") in "dropbox.desktop" file as showed below.[Desktop Entry] Name=Dropbox GenericName=File Synchronizer Comment=Sync your files across computers and to the web Exec=dropbox start Terminal=false Type=Application Icon=dropbox Categories=Network;FileTransfer; Keywords=file;synchronization;sharing;collaboration;cloud;storage;backup; StartupNotify=false
To complement this solution, you need change the permissions of "dropbox.desktop" file. Normally, when a file is created, in GNU/Linux, file's permissions are 644 (-rw-r--r--). If file's permissions stay 644, then, Dropbox software overwrites your changes when restarted. Dropbox will put "-i" again in the red line showed above.
But, if you change "dropbox.desktop" file's permitions to 444 (-r--r--r--), then, Dropbox software can't overwrites your changes when restarted.For you change file's permissions, you need to execute this command in directory the file is located:
$ chmod 444 dropbox.desktop
I know it doens't solve real problem. But, stops appearing that so boring message permanentely.
Thanks!
Wow yes! I saw the same thing. When I tried to remove the -i, I found that Dropbox changed it back again. I like your approach. But since I didn't think of that, what I did was to simply note what applications I thought were hammering the system, like insync and spideroak, and added delays to their startup slots. So to be clear, it is still a workaround- Dropbox has to be first LOL.
On every one run Dropbox application either removes desktop file from autorun (when no selected) or copies dropbox.desktop from applications to autorun. Preventing this action (doesn't matter how) or modifying the source (accordingly) gonna be a workaround. 😉
- Walter
Hi Walter,
I think you are trying avoid to say that Dropbox ignore Linux users; you definitely know that this bug is very old and is completely ignored from Dropbox development! I understand, it's not very convenient; if you say something your salary can stop.
Hi bnpndxtr,
The problem comes from an imperfection in communication between the control script and the daemon. Control script don't follow the daemon start, but relies daemon will open a communication socket in a hardcoded timespan (very very wrong). On heavy loaded system (initial boot and login session start is a good example), it's very easy this hardcoded time limit be violated. In such situation, the script "decides" that the daemon isn't installed (one more stupid decision). That's where the problem (your message) comes from. As a workaround you can try delay the starting process (as I noted in the referred thread). This works for me, but is NOT final solution, definitely. Don't rely for a solution from Dropbox, but I would be glad some developer to refute me.
Hope this adds clarity.
@Здравко,
Thanks, I will try the dealy next. I've used that before to "fix" other startup issues with other apps.
@Walter,
I've reinstalled bfore and the fix is only temporary, and so I don't think there is a hard causal link there, but thanks for replying on it.
It's so boring this situation. And it is repeating all times when I boot my computer.
