[Support] ken-ji - Dropbox


Recommended Posts

2 hours ago, stavr0s13 said:

Hey ken-ji ,
Are you stillworking on it or it is dropped? 
Is there any other alternatives for true 2 way sync between dropbox <-> unraid?
How can i set a VM doing the sync? As i read somewhere someone done it.

Thanks!!

You might be interested in this post which shows how I have Dropbox working with this container

Link to comment
2 minutes ago, itimpi said:

You might be interested in this post which shows how I have Dropbox working with this container

Just to be sure. You pointed your docker to /mnt/cache/Dropbox right?
Does it working as it should? Or did you had any problems?
And lastly. is it safe to remove the lines that does the move from old dropbox home to the new?

Sorry for the maybe stupid questions but i'm fairly new to linux terminal ecosystem.

Link to comment
17 minutes ago, stavr0s13 said:

Just to be sure. You pointed your docker to /mnt/cache/Dropbox right?

That was were the docker image is mounted, so yes that is where I pointed the container for storing dropbox files.   This then appears by default as the User Share 'Dropbox' so you can access the contents from other machines.  I pointed the config mount point For the container to /mnt/cache/appdata/dropbox. 

 

19 minutes ago, stavr0s13 said:

Does it working as it should? Or did you had any problems?

Seems to work fine as far as I can tell.   I have been running like this for some months now.

 

When you first start the docker container you need to open the container's log file to get the URL to link it to your Dropbox account.  Also if you are using a free dropbox account you have to make sure that you have not exceeded the limit of 3 devices that is now imposed on free accounts.

23 minutes ago, stavr0s13 said:

And lastly. is it safe to remove the lines that does the move from old dropbox home to the new

Yes.  If you do that you should find that any existing files in your Dropbox account get synced down to the Unraid server.

 

I set it up as a script both so I could remember the steps and also to automate steps on starting/stopping the array, but there is nothing stopping you from running each command manually the first time around to get a feel for it.

 

Feel free to ask further questions and supplest any improvements I could make to the scripts.

Link to comment
14 minutes ago, itimpi said:

Feel free to ask further questions and supplest any improvements I could make to the scripts.

Ok i'll write exactly what i'm doing to verify.


The script i use is this.
I've noticed you had a "#" in front of DROPBOXSIZE. Removed it.
I've also delete /mnt/user/appdata/dropbox and delete Dropbox docker from previously installed apps on CA.
/mnt/user/DropboxTest is not on share list and it doesn't exist now

#!/bin/bash
#  Script (partially commented out) for moving dropbox to a loopback image file
#  This gets around the restriction of Dropbox now only supporting ext4 on Linux
#  (see https://popey.com/blog/posts/fixing-broken-dropbox-sync-support.html)
#
#  we need to leave active the bit about mounting the image at array start

# Location of the image which will contain the new ext4 partition
# Typically this would be on the cache but this is not mandatory.
DROPBOXDISK=/mnt/user/
DROPBOXFILE=$DROPBOXDISK/DropboxTest.img

# Current location of my existing Dropbox folder
# (using User Share means we do not need t/ know device currently used)
DROPBOXHOME=/mnt/user/DropboxTest

# What size is the Dropbox image file going to be. It makes sense to set this
# to whatever the capacity of your Dropbox account is, or a little more.
DROPBOXSIZE="2500G"

# Start by making sure the disk to be used is present
if [ ! -e $DROPBOXDISK ]; then
  logger -s "ERROR:  $DROPBOXDISK disk not present"
  exit -1
else
  # ...and that we have not already followed this process
  if [ -e $DROPBOXFILE ]; then
    logger -s "Found existing $DROPBOXFILE"
  else
    # Create a 'sparse' file which will start out small and grow to the maximum
    # size defined above. So we don't eat all that space immediately.
    sudo dd if=/dev/zero of="$DROPBOXFILE" bs=1 count=0 seek="$DROPBOXSIZE"

    # Format it ext4, because Dropbox Inc. says so
    sudo mkfs.ext4 "$DROPBOXFILE"

    # Make a new Dropbox folder to replace the old one. This will be the mount point
    # under which the sparse image file will be mounted.  We want to make sure it is
    # on the same device as the image file.
    sudo mkdir $DROPBOXDISK/`basename $DROPBOXHOME`

    # Set ownership and permissions on the new folder so Dropbox has access
    # (generic Linux case)
    # sudo chown $(id -un) "$DROPBOXHOME"
    # sudo chgrp $(id -gn) "$DROPBOXHOME"
    # (Unraid specific case)
    sudo chown nobody "$DROPBOXHOME"
    sudo chgrp users "$DROPBOXHOME"

    # Make sure the mount point can't be written to if for some reason the partition 
    # doesn't get mounted. We don't want dropbox to see an empty folder and think 'yay, let's delete
    # all his files because this folder is empty, that must be what they want'
    sudo chattr +i "$DROPBOXHOME"
 
    # Mount the sparse file at the dropbox mount point
    sudo mount -o loop "$DROPBOXFILE" "$DROPBOXHOME"

    # Let's unmount it as we normally want to use fstab entry
    sudo umount "$DROPBOXHOME"
  fi
fi

# Create a line in our /etc/fstab so this gets mounted on every boot up
status=`grep -o "$DROPBOXHOME" /etc/fstab`
if [ $? -eq 0 ]; then
  logger -s "Entry for $DROPBOXHOME already present in /etc/fstab"
else
  echo "$DROPBOXFILE" "$DROPBOXHOME" ext4 loop,defaults,rw,relatime,exec,user_xattr 0 0 | sudo tee -a /etc/fstab
  logger -s "Entry for $DROPBOXHOME added to /etcfstab"
fi

# This will mount as per the fstab 
sudo mount -a

logger -s "$DROPBOXFILE mounted at $DROPBOXHOME"
exit 0

After running this script, DropboxTest folder created and DropboxTest.img file also created under /mnt/user/

Installing Dropbox Docker from CA now.
/mnt/user/appdata/dropbox is the config folder
/mnt/user/DropboxTest is the data folder
Pulled image, go to log, copy link and allow access.
Computer is now linked.
After that i see the log and it looks like its restarting. twice. 
then i get a bunch of  WARNING:tornado.access:404 HEAD /blocks/225260633/YgzjUPL0SS1U22ovWyju6qgqHYqJb1uNMuvRRotfWH4 (172.17.0.1) 11.81ms
Ok, lets restart the docker.
Now looks like its working fine.
running du -sh /mnt/user/DropboxTest shows the size increasing.

But after some minutes i get again this WARNINGs after restarting the docker by itself twice then sits there spitting WARNINGs, but file size still increasing.

Now, how should i setup this folder so i can access it via SMB and how i can see the status of the dropbox syncing. I know there is the dropbox.py somewhere inside but i dont know how to use it.

I tried to provide as more info as i could to help you instead of guessing!


Thanks

Link to comment



Ignore the Warning messages - they appear to be part of normal operation.   The only one you need to watch out for in my experience is whether it says it is no longer linked so you need to repeat the relink process.

Not sure if there is an easy way to tell if it has finished syncing other than the fact that the number of files (and space occupied by them) stops  increasing.   In my experience it ‘just works’ so I do not need to do anything else about it.   I tend to not be syncing very large files so there is not normally much delay in propagation.    It can be useful to have another device (I have an iPad) that is connected to your Dropbox account via the web interface if there is any particular file of concern.    If it shows up in the web interface and not on the Unraid server it is probably syncing.

 

i do not know if there is anything that could be done at the container level to get the sync status.    Not knowing enough about how the internals of DropBox works this is not something I have ever looked at.   I was just very glad to have it syncing to my Unraid server.

 

regarding the SMB side you will now have a User Share called Dropbox.   Just set the SMB settings like you would for any other share on Unraid.

Edited by itimpi
Link to comment
30 minutes ago, itimpi said:



Ignore the Warning messages - they appear to be part of normal operation.   The only one you need to watch out for in my experience is whether it says it is no longer linked so you need to repeat the relink process.

Not sure if there is an easy way to tell if it has finished syncing other than the fact that the number of files (and space occupied by them) stops  increasing.   In my experience it ‘just works’ so I do not need to do anything else about it.   I tend to not be syncing very large files so there is not normally much delay in propagation.    It can be useful to have another device (I have an iPad) that is connected to your Dropbox account via the web interface if there is any particular file of concern.    If it shows up in the web interface and not on the Unraid server it is probably syncing.

 

i do not know if there is anything that could be done at the container level to get the sync status.    Not knowing enough about how the internals of DropBox works this is not something I have ever looked at.   I was just very glad to have it syncing to my Unraid server.

 

regarding the SMB side you will now have a User Share called Dropbox.   Just set the SMB settings like you would for any other share on Unraid.

In my case should be DropboxTest right?
When i go to \\192.168.1.250\DropboxTest all i see is folders etc,var,root,home and more. but when i do ls /mnt/user/DropboxTest it gives me back the dropbox folders..

As for the status. inside the docker at /usr/local/bin there is the dropbox.py. 
normaly when you do dropbox.py status. it spits out the status. but not its says python3 no suchfile or dir.
(i remember it was working in the past)

Link to comment

It might be worth checking what disk(s) contain a folder DropboxTest.    There should only be one.   Having more than one would definitely confuse things as you would not know which one had the Dropbox image file mounted on it.    You might want to explicitly specify a disk drive (e.g. /mnt/diskX) rather than ‘/mnt/user’ for the location (where I was using /mnt/cache) as that gives you more control.    It will still show up under /mnt/user as all top level folders on any drive show up there.

Link to comment
4 hours ago, itimpi said:

It might be worth checking what disk(s) contain a folder DropboxTest.    There should only be one.   Having more than one would definitely confuse things as you would not know which one had the Dropbox image file mounted on it.    You might want to explicitly specify a disk drive (e.g. /mnt/diskX) rather than ‘/mnt/user’ for the location (where I was using /mnt/cache) as that gives you more control.    It will still show up under /mnt/user as all top level folders on any drive show up there.

I would specify a disk drive, would be easier! 

Thanks for your help!!

Link to comment

I'm considering dropping this Dropbox image given that I'm personally moving away from Dropbox, because of their limit to 3 devices policy.

I'm experimenting on rclone and checking on how I can work with my workflow on it.

That said, I'd like to look into a way to automate dropbox + fixed size loopback image for the Dropbox data directory.

Edited by ken-ji
Link to comment
  • 2 weeks later...

Hi!

 

I used this docker until it worked on btrfs and I really would like to use it in the future too.

Two weeks ago there was Beta Build 77.3.127 where they managed to "Add support for zfs (on 64-bit systems only), eCryptFS, xfs (on 64-bit systems only), and btrfs filesystems in Linux". Also there is a newer Stable Build 77.4.131.

 

If I reinstall the docker, it pulls down "dropbox-lnx.x86_64-67.4.83" not the newest one. Also tried to manually update to newest version with no success...

  • Upvote 1
Link to comment
  • 2 weeks later...
On 7/25/2019 at 4:37 AM, aspartam said:

Hi!

 

I used this docker until it worked on btrfs and I really would like to use it in the future too.

Two weeks ago there was Beta Build 77.3.127 where they managed to "Add support for zfs (on 64-bit systems only), eCryptFS, xfs (on 64-bit systems only), and btrfs filesystems in Linux". Also there is a newer Stable Build 77.4.131.

 

If I reinstall the docker, it pulls down "dropbox-lnx.x86_64-67.4.83" not the newest one. Also tried to manually update to newest version with no success...

Good to know they're not completely stupid. Does this mean the solution above won't be needed soon?

Link to comment
  • 3 months later...

(warning: Docker newbie)  I just installed it and am getting the 

 

Quote

[ALERT]: You're using an old version of Dropbox. Please update to the latest version to continue using Dropbox.

error. I saw a post from back in 2017 that this was an issue, but am not clear on how it was resolved. The docker interface in unRaid claims that the application is up to date (and have already executed a check for updates). 

Apologies if I'm leaving out any critical information, this is my first experience with docker containers. 

Link to comment

Apologies, as I've been busy with a whole bunch of other things, living away from my server, and am considering relegating Dropbox to a lower usage tier - because I don't like their decision to limit the free tier to 3 or less devices.

 

I'm going to rebuild the docker image and see if it still works.

Link to comment
2 hours ago, ken-ji said:

Apologies...

 

I'm going to rebuild the docker image and see if it still works.

No need for apologies; volunteer support when you're moving away from a platform is a tough spot. Thanks for checking, though! If it doesn't update, I'll try a different method. Thanks, again!

Link to comment
  • 2 weeks later...

I've rebuilt the docker image. and it seems to be running on my setup (but I have not linked it to my account as I do not have a free slot at the moment)

as an FYI, the docker image is built with whatever is the latest dropbox download available. While the container is running, it can upgrade itself (as the dropbox app expects to be able to do so) and the upgrade is stored in the appdata folder.

So the container in theory should never become too old (unless Dropbox deprecates the app), but I need to rebuild the docker image to contain a fresh app version. It should be possible to add routines to upgrade the docker container after install, but I'll need to see and test that approach.

Edited by ken-ji
Link to comment

I've clearly done something wrong, but I'm at a loss as to what. I initially tried updating the container and came up with an error so I deleted the container and reinstalled from Community Applications. I got (effectively) the same error:

 

Quote

 

dropbox: locating interpreter
dropbox: logging to /tmp/dropbox-antifreeze-Rn6B9w
dropbox: initializing
dropbox: initializing python 3.7.2
dropbox: setting program path '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-85.4.155/dropbox'
dropbox: setting home path '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-85.4.155'
dropbox: setting python path '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-85.4.155:/dropbox/.dropbox-dist/dropbox-lnx.x86_64-85.4.155/python-packages-37.zip'
dropbox: python initialized
dropbox: running dropbox
dropbox: setting args
dropbox: applying overrides
dropbox: running main script
dropbox: load fq extension '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-85.4.155/cryptography.hazmat.bindings._constant_time.cpython-37m-x86_64-linux-gnu.so'
dropbox: load fq extension '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-85.4.155/cryptography.hazmat.bindings._openssl.cpython-37m-x86_64-linux-gnu.so'
dropbox: load fq extension '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-85.4.155/cryptography.hazmat.bindings._padding.cpython-37m-x86_64-linux-gnu.so'
dropbox: load fq extension '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-85.4.155/psutil._psutil_linux.cpython-37m-x86_64-linux-gnu.so'
dropbox: load fq extension '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-85.4.155/psutil._psutil_posix.cpython-37m-x86_64-linux-gnu.so'
dropbox: load fq extension '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-85.4.155/linuxffi.pthread._linuxffi_pthread.cpython-37m-x86_64-linux-gnu.so'
dropbox: load fq extension '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-85.4.155/cpuid.compiled._cpuid.cpython-37m-x86_64-linux-gnu.so'
dropbox: load fq extension '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-85.4.155/apex._apex.cpython-37m-x86_64-linux-gnu.so'
Traceback (most recent call last):
File "dropbox/client/main.pyc", line 8, in <module>
File "dropbox/client/features/catalina_migration/catalina_migration_controller.pyc", line 19, in <module>
File "dropbox/client/features/catalina_migration/catalina_account_context.pyc", line 13, in <module>
File "dropbox/client/features/catalina_migration/alert_dialog.pyc", line 10, in <module>
File "dropbox/client/features/file_locking/base_file_locking_alert.pyc", line 13, in <module>
File "dropbox/client/features/legacy_ui_launcher.pyc", line 21, in <module>
File "dropbox/client/configuration/manager.pyc", line 45, in <module>
File "dropbox/client/configuration/utils.pyc", line 18, in <module>
File "dropbox/client/autorestart.pyc", line 33, in <module>
File "dropbox/foundation/html_views/common/__init__.pyc", line 9, in <module>
File "dropbox/foundation/html_views/common/content_metadata.pyc", line 18, in <module>
File "dropbox/foundation/html_views/common/interface.pyc", line 18, in <module>
File "dropbox/foundation/context/__init__.pyc", line 14, in <module>
File "apex/__init__.pyc", line 6, in <module>
File "<_bootstrap_overrides>", line 153, in load_module
ImportError: libdropbox_apex.so: cannot open shared object file: No such file or directory
!! dropbox: fatal python exception:
['Traceback (most recent call last):\n', ' File "dropbox/client/main.pyc", line 8, in <module>\n', ' File "dropbox/client/features/catalina_migration/catalina_migration_controller.pyc", line 19, in <module>\n', ' File "dropbox/client/features/catalina_migration/catalina_account_context.pyc", line 13, in <module>\n', ' File "dropbox/client/features/catalina_migration/alert_dialog.pyc", line 10, in <module>\n', ' File "dropbox/client/features/file_locking/base_file_locking_alert.pyc", line 13, in <module>\n', ' File "dropbox/client/features/legacy_ui_launcher.pyc", line 21, in <module>\n', ' File "dropbox/client/configuration/manager.pyc", line 45, in <module>\n', ' File "dropbox/client/configuration/utils.pyc", line 18, in <module>\n', ' File "dropbox/client/autorestart.pyc", line 33, in <module>\n', ' File "dropbox/foundation/html_views/common/__init__.pyc", line 9, in <module>\n', ' File "dropbox/foundation/html_views/common/content_metadata.pyc", line 18, in <module>\n', ' File "dropbox/foundation/html_views/common/interface.pyc", line 18, in <module>\n', ' File "dropbox/foundation/context/__init__.pyc", line 14, in <module>\n', ' File "apex/__init__.pyc", line 6, in <module>\n', ' File "<_bootstrap_overrides>", line 153, in load_module\n', 'ImportError: libdropbox_apex.so: cannot open shared object file: No such file or directory\n'] (error 3)

Did I miss some dependency or other pre-installation setup requirement?

Link to comment
1 hour ago, jordan said:

I've clearly done something wrong, but I'm at a loss as to what. I initially tried updating the container and came up with an error so I deleted the container and reinstalled from Community Applications. I got (effectively) the same error:

 

Did I miss some dependency or other pre-installation setup requirement?

I have the same error after updating too.

Link to comment
3 hours ago, jordan said:

I've clearly done something wrong, but I'm at a loss as to what. I initially tried updating the container and came up with an error so I deleted the container and reinstalled from Community Applications. I got (effectively) the same error:

 

Did I miss some dependency or other pre-installation setup requirement?

you'll need to delete .dropbox-dist from the appdata folder - by default /mnt/user/appdata/dropbox

the broken versions have left incomplete .dropbox-dist folders which is now screwing it up.

Link to comment
Just now, ken-ji said:

you'll need to delete .dropbox-dist from the appdata folder - by default /mnt/user/appdata/dropbox

the broken versions have left incomplete .dropbox-dist folders which is now screwing it up.

Ah - makes sense. I didn't think to go back and scrub the old directories out manually. I'll try that. 

Link to comment

That got it running. One last question (I hope) - After linking I'm greeted with the ominous

 

[ALERT]: So your files continue to sync, sign in to your Dropbox account and move Dropbox to a supported file system.

 

I just paged back through this thread, and I see where it came up last year when DB kicked everything but ext4 to the curb, but I can't tell whether there was a workaround built in, or everyone just bailed on the protected array and using external USB formatted to ext4? Or are those using it installing a trick like https://www.linuxuprising.com/2018/11/how-to-use-dropbox-on-non-ext4.html ?

Link to comment
2 minutes ago, ken-ji said:

I think the error is because when you run Dropbox on the array, it correctly sees the filesystem as shfs which is artificially unsupported.

Some users have just created a ext4 loopback image. I suppose with the container working again, you can have it on the cache drive

Okay, thanks. That's definitely going to take some reading. 

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.