[Support] ken-ji - Dropbox

[ken-ji]

Information

Overview: Support for Docker image dropbox-docker by ken-ji.

Application: Dropbox - https://www.dropbox.com/

Docker Hub: https://hub.docker.com/r/roninkenji/dropbox-docker/

GitHub: https://github.com/roninkenji/dropbox-docker

 

Please post any support queries relating to this Docker image here.

 

EDIT: Solved the dropbox app updating issue

I've released an update and will post the correct way to change your existing install to the self updating version.

 

Migration Steps:

• Stop the Container
  
• make sure the older app and config directories are under the same appdata folder (they are by default)
  
• rename the app directory to .dropbox-dist
  
• rename the config directory to .dropbox
  
• create a Dropbox directory
  
• it should look like this now:
  

[email protected]:~# tree -aL 1 /mnt/cache/appdata/Dropbox/
/mnt/cache/appdata/Dropbox/
+-- .dropbox
+-- .dropbox-dist
\-- Dropbox

• Reconfigure the container as in the next post.
  

This worked for me...

[ken-ji]

Add the docker and configure the folders:

refer to attachment: Container Mounts.png

 

Then check the docker container logs for a link to copy and paste to link your dropbox container.

 

[Squid]

Will be added to Community Applications ~ 5pm EST

[weirdcrap]

Does your Dropbox docker support selective sync (ie I can pick which folders I want to be synchronized)? Do any of the current Dropbox dockers support this? I know it is possible in the official application so if not I might just make a Linux VM and use the official dropbox application for my needs.

[ken-ji]

There is the dropbox.py cli for dropbox installed in the container. It probably can be used to selective sync, but I haven't bothered.

[t3]

i had some success "setting up" selective sync by copying a file from windows install over to the config folder of the docker;

 

after installing and linking the docker, the dropbox config is created here: appdata/Dropbox/config/instance1 and contains a file named unlink.db since size and type and name suggested it might contain just everything that should not be synced, i just copied it from my windows box over to the docker config, and as far i can tell it works... of course only suitable if that is not going to change regularly.

 

unfortunately there are problems with this docker with files that contain extended characters (i.e. german umlauts)... seems like the charset setting is missing or wrong?

[t3]

oh, and btw, it would be great if it was possible to set up a meaningful name for the dropbox instance prior linking...

[ken-ji]

I'll try the non-latin and or extended characters later, as I now realize that I haven't worked tried that at all.

 

As for the name, its a side effect of the docker's host name which is randomly generated everytime a new image is created. Dockers are not suppose to care about that and you can go into your Dropbox security page to rename the host.

 

[t3]

As for the name, its a side effect of the docker's host name which is randomly generated everytime a new image is created. Dockers are not suppose to care about that and you can go into your Dropbox security page to rename the host.

thanks for hinting this; totally missed it, since there is no context menu/button/indication whatsoever that one can edit the names by simply double clicking them...

[ken-ji]

Ok. I've fixed the container to have a LANG=en_US.UTF-8. This should allow the running dropbox process to create files and directories with the proper Unicode names. "Works for me" is in effect.

[t3]

... as far as my files were affected, i can confirm it works now; tested with sync triggered from "both" ends (web and local) and all were showing up correctly on either side - thanks a lot!

[weirdcrap]

There is the dropbox.py cli for dropbox installed in the container. It probably can be used to selective sync, but I haven't bothered.

Ok I created a test account so I wouldn't hose my real dropbox if I did something stupid.

 

Where exactly is the dropbox.py file, in the docker.img itself? I assumed that it would be in one of the mapped container volumes but I can't seem to find it.

 

Well I think I found. It appears as though dropbox.py is in /usr/local/bin/dropbox.py inside the docker but when I run the exclude add command I get an error. I am trying to follow along loosely with these instructions but am getting an error that Dropbox isn't running.

 

The command I tried:

 

[email protected]:/# docker exec Dropbox /usr/local/bin/dropbox.py exclude add Dropbox/test

Dropbox isn't running!

[ken-ji]

Dropbox is running as user nobody inside the docker.

so to mess with CLI inside this docker, it is necessary to use

docker exec -it --user nobody Dropbox /bin/bash -l

 

[Zan]

Hi Kenji,

 

I set up this docker container just using the defaults but noticed that I then didn't have any access to files. So I set the ENV variables for DROPBOX_USER and DROPBOX_USERID so that the user I regularly access my unRAID box with can get to the files, but now the container won't start and the log file is empty. Here's the command line:

 

[email protected]:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker run -d --name="Dropbox" --net="bridge" -e DROPBOX_USER="zan" -e DROPBOX_USERID="1000" -e TZ="Australia/Sydney" -p 17500:17500/tcp -p 17500:17500/udp -v "/etc/localtime":"/etc/localtime":ro -v "/mnt/cache/appdata/dropbox/config":"/dropbox/.dropbox":rw -v "/mnt/cache/appdata/dropbox/app":"/dropbox/.dropbox-dist":rw -v "/mnt/user/Dropbox":"/dropbox/Dropbox":rw roninkenji/dropbox-docker

 

Any ideas?

[ken-ji]

You should make sure the folders mapped to the docker (in this case: /mnt/cache/appdata/dropbox, /mnt/user/Dropbox and all sub folders are owned by the same user "zan"), because you've already run the docker once,  the folders have been generated and are causing some issues with the access permissions.

[Zan]

You should make sure the folders mapped to the docker (in this case: /mnt/cache/appdata/dropbox, /mnt/user/Dropbox and all sub folders are owned by the same user "zan"), because you've already run the docker once,  the folders have been generated and are causing some issues with the access permissions.

 

Thanks ken-ji, all good now 

[eg4190]

I'm getting a weird syncing issue with this container.  If I drag/update files into my local Dropbox folder on the various machines I have around the house, the Docker instance on my server is syncing the files properly.  But any changes that originate on the server are not being reflected on my local machines.

 

I would like certain automated downloads of mine to move over to Dropbox automatically, but this currently isn't working because the unRAID Docker instance doesn't seem to upload anything.  Any ideas?

[ken-ji]

are you sure the new files coming from the unraid side are owned by the same user as DROPBOX_USER (default nobody) as the default user for new files could be root, and then the dropbox won't be able to access the due to the permission mismatch

[eg4190]

That's actually something I'm confused about -- I'm assuming all of the other processes are creating new files as root, because none of the other containers specify a user.  When I Google how to change the default user for new files, I wind up reading a lot of responses about how doing so is evil.

 

I do have a non-root user account set up on my unRAID box, but I'm not sure how to set that account as the default user for new files, so that all of my other Docker containers are writing to the Dropbox folder as that user (I'm assuming the other containers all have access to the same user accounts as the unRAID box?).  Any help would be much appreciated.

[ken-ji]

Sorry, I'm not sure about the defaults anymore (because I run all my shares secured for user/password access)

Here's my recommended fix for you:

• From a terminal, get the uid of your user
  

# id ken-ji
uid=0(ken-ji) gid=100(users) groups=100(users)

Typically it will be 100

• Make sure Dropbox docker is stopped.
  

• Execute
  

# chown -Rv uid:users /mnt/user/appdata/Dropbox/*

Replace

uid = with the uid value (or your username)

/mnt/user/appdata/Dropbox/ - replace with where your dropbox folders are (Dropbox, .dropbox-dist, .dropbox), in my case, they are all under /mnt/user/appdata/Dropbox

You can specify all three folders separated by space in the command

• Modify the docker settings, and set the environment variables:
  

DROPBOX_USER={myuser}
DROPBOX_USERID={uid}

 

• Startup the docker, it should work then.
  

If you don't feel comfortable, you can destroy all the folders, and restart the docker from scratch, but make sure to set the environment variables before the first start of the docker.

[eg4190]

Thanks for the response.  So I guess what I really want is for the Dropbox container to run as root.  Everything else on my server is running as root and creating downloaded files as root:root, and I've had no issues witht his.  I have no personal information on my server and it's just movies, music and comic books, so I really don't care about the security implications of this.

 

If I were to run this Dropbox container under my non-root username, I would also need to move every other container over to that username.  So my preference would be to just run this Dropbox container as root.

 

I tried this by entering DROPBOX_USER = root, DROPBOX_USERID = 0, DROPBOX_GROUP = root, and DROPBOX_GROUPID = 0.

 

I'm getting this in the log after activation:

 

usermod: user root is currently used by process 1

WARNING:tornado.access:404 HEAD /blocks/510013235/NV50NTkhIybNc_1--VF0mY4chlBSPeR7fQZwTf1bf4k (172.17.42.1) 678.61ms

WARNING:tornado.access:404 HEAD /blocks/510013235/NV50NTkhIybNc_1--VF0mY4chlBSPeR7fQZwTf1bf4k (172.17.42.1) 716.83ms

...

...

 

And so on, with a few thousand of those 404 errors.

...

...

 

Finally, the container dies with this at the end of the log:

 

/usr/local/bin/myinit.sh: line 14: 14 Killed su -l ${DROPBOX_USER} -c "/dropbox/.dropbox-dist/dropboxd"

 

 

So apparently the container doesn't like running as root, but I'm getting similar 404 errors (minus the first and last error) running as either "nobody" or my non-root UID, just because neither of those accounts has access to the files the other containers are putting in the Dropbox folder.

[ken-ji]

I'm afraid you'll need a different docker image to support the run as root (particularly since its not aligned with best practices)

No promises, but I'll see if I can whip something up.

[mattcoughlin]

dropbox is up and running fine but if i try to access the dropbox data folder it says i don't have permission. is this an expected outcome? i have tried running another version of dropbox docker and had the same result. my hope was to be able to copy my uploaded photos out of the dropbox folder to my permanent storage folder.

[webrob123]

Not sure why but the contents of my Dropbox folder were deleted last night. I'd actually just cleared it out a few days ago using the web client to reclaim space. So it was pretty much empty apart from a few folders and a couple images the desktop client had grabbed from my phone.

 

I use 2-factor auth for all the desktop and mobile clients that I connect to Dropbox. When I connected via unRaid I used the link and no 2-factor was required, which was a new one for me.

 

So just after my desktop notified me that all the folders and images in my Dropbox had been deleted I decide to check the unRaid share. It was late, but I'm 99.99% certain that the Dropbox Docker data folder had disappeared off my cache drive. I decide to stop the unRaid Dropbox Docker until I could figure out what had happened. I was then able to restore the deleted files and folders via the web client and they all appeared back in my desktop dropbox folder.

 

The unRaid Docker instance has remained off since this point and today I checked the appdata folder where the Dropbox data folder had disappeared from yesterday and it is now back there again. I think this is something to do with the fact that it ended up being on my cache drive. Should the cache drive not be used for Dropbox data and be considered ephemeral. I'm pretty sure I read somewhere that the appdata folder should be on the cache drive. Somehow I think my misunderstanding of this is why the folder disappeared.

 

Can anyone shed any light on what they think I'm doing wrong. I followed these instructions to the letter to get it up and running:

 

http://lime-technology.com/forum/index.php?topic=46401.msg443278#msg443278

 

[ken-ji]

dropbox is up and running fine but if i try to access the dropbox data folder it says i don't have permission. is this an expected outcome? i have tried running another version of dropbox docker and had the same result. my hope was to be able to copy my uploaded photos out of the dropbox folder to my permanent storage folder.

 

Whats the setting of your share where the Dropbox folder is located? I think you have this issue because the settings of my docker is allow access only to the Dropbox user. (default is nobody) - which means only guest accesses can actually access the Dropbox. If you are accessing using a user account, you can change the userid running Dropbox see above posts.

 

Note: I cheat in my unraid since i have this in the file /boot/config/smb-extra.conf

[global]
    force user = nobody

which makes all server side accesses by the nobody user, the username and password for access over SMB is for authorization only.