cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Learn all about how Alex on the Community team used Dropbox in college here!

Dropbox installs & integrations

Connect your tools and content together with help from the Dropbox Community. Join a discussion or post a question of your own to get started.

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Cannot run latest dropboxd on Centos 7 with glibc 2.17, and flatpak version crashes

Cannot run latest dropboxd on Centos 7 with glibc 2.17, and flatpak version crashes

neekfenwick
Helpful | Level 6

Hi all, I've seen a few threads about dropbox on Centos 7 and am facing this problem myself.  We've developed a procedure within our team using Dropbox on our Windows office machines and now would like to install dropboxd on our CentOS 7 web server so it can easily share files with the team.

 

I know this is outside of the System Requirements for Linux (https://help.dropbox.com/installs-integrations/desktop/system-requirements#linux) but I would very much like this to work.

 

The thread at https://www.dropboxforum.com/t5/Dropbox-installs-integrations/CentOS-7-support/m-p/316718 contains some useful info, so I installed the latest headless version from https://www.dropbox.com/install-linux and get:

 

ImportError: /lib64/libc.so.6: version `GLIBC_2.18' not found (required by /home/premier/.dropbox-dist/dropbox-lnx.x86_64-99.4.501/libdropbox_apex.so)

 

It seems CentOS 7 is based on glibc 2.17 and this is basically impossible to update to 2.18, I guess one would have to install CentOS 8 which is not an option for us at this time.  Is it possible to get an older version of the headless version, that was linked against glibc 2.17?  I realise this would be an older version of dropbox but at least it might run! 🙂

 

The above thread also mentions flatpak, so I went through that procedure as well, but the output of `flatpak run -vvv com.dropbox.Client`  ends with a mysterious error:

 

F: Running '/usr/libexec/flatpak-bwrap --args 25 dropbox-app'

 

Is the Flatpak version supported on this forum, or do you consider it unsupported third party packaging?

 

Would dearly love to get this working, I've had to write a lot of horrible PHP that uses the Dropbox API to upload files to our shared space that would be completely unnecessary if the daemon would run and sync the files automatically.  Thank you!

3 Replies 3

Re: Cannot run latest dropboxd on Centos 7 with glibc 2.17, and flatpak version crashes

neekfenwick
Helpful | Level 6

Update! 🙂 I tried following the 'compile from source' instructions at https://help.dropbox.com/installs-integrations/desktop/linux-commands but it depends on nautilus packages that made me think it was a dead end, since ours is a headless server and normally I wouldn't want to clutter it up with GUI related packages.  However, I've bit the bullet and installed everything it asked for, and seem to have compiled a dropbox binary, however it then downloads the daemon which then crashes with the glibc error in my post  above.

 

Conversation at https://forums.centos.org/viewtopic.php?t=70253 confirms that it's not really expected to work, and they mention flatpak which also doesn't work for me, so I'm back at square 1.

Re: Cannot run latest dropboxd on Centos 7 with glibc 2.17, and flatpak version crashes

neekfenwick
Helpful | Level 6

I'm pretty sure I posted a third message here with details of debugging flatpak with strace, but it seems to have disappeared.  If a moderator sees this, could you please check if it was removed, perhaps because its contents appeared to be spam? (it was a lot of ugly strace output)

Re: Cannot run latest dropboxd on Centos 7 with glibc 2.17, and flatpak version crashes

neekfenwick
Helpful | Level 6

With strace I was able to capture more output (looks like it was trying to write to stderr fd=2 but it didn't print when run from the command line), with: strace flatpak run -vvv com.dropbox.Client 2>&1

 

write(2, "Creating new namespace failed, l"..., 139Creating new namespace failed, likely because the kernel does not support user namespaces. bwrap must be installed setuid on such systems.)

 

Turns out my CentOS 7 system is using a rather old kernel kernel-3.10.0-1127.10.1.el7.x86_64.rpm and I read a report that moving to a newer kernel like 4.4 would help, so I set up ELRepo and installed the latest version of the linux kernel and crossed my fingers (https://www.howtoforge.com/tutorial/how-to-upgrade-kernel-in-centos-7-server/ was useful).  Now I am running kernel version 5.7.4-1.el7.elrepo.x86_64 and the server is still operating correctly, however, dropbox still refuses to run.  I tried uninstalling/reinstalling the com.dropbox.Client flatpak app just in case.

 

I found you can run a shell within the flatpak environment of an app, with:

# flatpak -y install flathub org.gnome.Sdk//3.36

# flatpak run -vvv --command=sh --devel com.dropbox.Client

 

This gives me a shell, and given that the last line of output when trying to run the flatpak app normally is:

 

F: Running '/usr/libexec/flatpak-bwrap --args 25 dropbox-app'

 

I looked for dropbox-app and found /app/bin/dropbox-app which is a Python script that would try to run /app/extra/.dropbox-dist/dropboxd but gives this output:

 

# ./dropbox-app --debug
INFO:root:Trying to own the dropbox dbus name...
INFO:root:Looking for Dropbox configuration...
INFO:root:Dropbox configuration not found
INFO:root:Another instance of dropbox is already running but no Dropbox folder was found; launching the daemon again
INFO:root:Trying to own the dropbox dbus name (this time replacing existing ones)...
INFO:root:Not the main launcher instance. Exiting

 

It seems to think another instance is running, however I cannot see any likely looking processes:

 

# ps -aef | grep -i dropb
root 18 2 0 05:07 ? 00:00:00 grep -i dropb

 

Looking into the dropbox-app python script, it prints that "but no Dropbox folder was found" message if the get_dropbox_directory() function fails, and here my knowledge of flatpak falls down.   I can't tell if running the app from the debug shell is a good idea.  Is it going to be able to access the dropbox folder in the host system's user directory?  the /app filesystem is mounted readonly so I cannot hack the script to try to debug it.

 

All pretty frustrating 🙂

Who's talking

Top contributors to this post

What do Dropbox user levels mean?
Need more support?