Jump to content

[Support] ken-ji - Dropbox

Recommended Posts


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:

root@MediaStore:~# tree -aL 1 /mnt/cache/appdata/Dropbox/
+-- .dropbox
+-- .dropbox-dist
\-- Dropbox

  • Reconfigure the container as in the next post.

This worked for me... :D

Link to comment

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?

Link to comment

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.


Link to comment
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...

Link to comment

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:


root@VOID:/# docker exec Dropbox /usr/local/bin/dropbox.py exclude add Dropbox/test

Dropbox isn't running!

Link to comment

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:


root@localhost:# /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?

Link to comment

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.

Link to comment

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  :)

Link to comment

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?

Link to comment

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.

Link to comment

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/*


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:



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

Link to comment

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 ( 678.61ms

WARNING:tornado.access:404 HEAD /blocks/510013235/NV50NTkhIybNc_1--VF0mY4chlBSPeR7fQZwTf1bf4k ( 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.

Link to comment

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:




Link to comment

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

    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.



  • Upvote 1
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.

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.

  • Create New...