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

 

I'm fairly sure I know the problem - if you did follow the instructions to the letter, does the share backups have Use cache disk: Yes? because it should be either cache only or No, because I'm not sure what the mover will do to Dropbox when data is moved from the cache disk to the array.

 

Yep, it was set to Yes. So I need to treat that setting as ephemeral by the sound of it. That is it won't be lost, but it can't be guaranteed to stay on the cache drive all the time as it might move to the array?

 

So I should either use No, which will put data on the array or cache only, which would persist it on the cache. With the last option leading to no protection?

Yes, you are correct on your interpretation.

 

FYI. Use cache disk set to yes will cache writes and changes to the share on the cache disk until the Mover applet is run (cf http://lime-technology.com/wiki/index.php/UnRAID_6/Getting_Started#Assigning_Devices_to_the_Array_and_Cache) When that happens, I have no idea what it looks like to the Docker app, which is probably why it deleted all your files.

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.

 

Thank you sir, this helped a lot.  I was fighting permissions issues.  Excellent docker, thank you for your work.

not sure what was wrong.  I had a corrupt docker last weekend and had to reinstall everything.  same issue occurred.  i usually will reset the permissions if i have a large number of files to add or copy off and when i did that this time it didn't unlink my account and everything seems to be running fine so i'm not going to touch anything. 

Hi kenji, I was having the same problem uploading files until I noticed that everything works fine until 2 levels of nesting (dropbox/folder1/).

 

From 3 levels thereafter, the files are downloaded without problems but are never uploaded (dropbox/folder1/folder2/).

 

Am I the only one with this problem? 

Hmm. first time i heard about this.

So I tried to create a deep directory structure

Dropbox/a/b/c/d

with the last dir containing a file e and a directory f

 

and surprisingly, the docker seems to think it was able to upload everything, but only a/b/c showed up in dropbox.com

forcing an exclude and removing it caused the directoryies to be upload properly.

Also creating the directories slowly (1 second in between) seems to work properly.

 

This might be a bug in the client. (the docker uses the official headless client)

Having problems setting this up correctly. 

 

As one of the other users mentioned, I only have a root user.  (I too am getting 404 errors)

 

I don't mind creating more users, but I want to be able to share the files over samba easy (no login/password) as I do now with the file shares. 

 

Do you mind giving a hand?

One suggestion I can give you is to put this inside /boot/config/smb-extra.conf

[global]
    force user = nobody

Then run the Tools | New Permissions to reset all the permissions and ownership to nobody:users (if they aren't already)

At this point starting and stopping the Array will ensure that all your SMB access is now via the nobody user.

Then just install the Dropbox docker. There should be no need to configure the DROPBOX_USER variable.

 

Thanks for posting on my other thread as well

 

Going to give it one more whirl.  Would you be up for a skype or some other kind of chat?  I'm seeming to have more problems than it seems I should with dropbox docker.

 

Here is my background info on this:

 

have a SMB share setup called filesever

I have a folder created underneath fileserver (which I created via a Windows workstation) called SupportDropbox

So the path SMB share I want dropbox to use is /fileserver/SupportDropbox (The full path is :/mnt/user/fileserver/SupportDropbox)

 

I do have other users besides root setup, but they do not write/access any files under /fileserver

 

Any other suggestions?

ok, it seems after I reset permissions, things seem to be syncing... however, when things sync to one of the workstations...

 

I see this in the log

WARNING:tornado.access:404 HEAD /blocks/254486766/-ip5ItUY8RKo-ThJgW_gbNUDSXDB3W2GhguRkuxfmeI (192.168.228.66) 17.36ms

 

Is there something I'm doing wrong or what should I check?

I'm a little stumped by your issue.

You've reset permissions.

Did you do the force user setting i suggested?

Did you reset the ownership of the dropbox config folders?

Could you post a screenshot of your Docker configuration?

 

I'm a little stumped by your issue.

You've reset permissions.

Did you do the force user setting i suggested?

Did you reset the ownership of the dropbox config folders?

Could you post a screenshot of your Docker configuration?

 

I'll check, but I don't remember forcing the user setting now that you mention it (again).

 

For the Dropbox config folders, I don't think I touched those. 

 

I first deleted the old app data Dropbox folder (which was the 'other' docker for Dropbox), then I reset permissions, and then installed your docker again.

 

I'll post up my docker advanced view in a bit once I get back to a PC.

 

But so far, syncing is working better now.  If I change something on a workstation, it changes within the docker/share. 

Ken-ji,

 

Seems that dropbox isn't syncing all folders, only the top few layers.  Anything I need to do?

 

Also, it seems if I change a file (such as delete it) from a pc (not the unraid server), it re-appears a few seconds later. 

 

Suggestions?

I can only speculate, but this might be an issue with the dropbox client in the docker (something went corrupt or awry).

Try deleting the docker and all the files/folders used by the docker (the three mapped directories). Don't attempt to save/reuse anything as that might make the dropbox client think you deleted everything and proceed to flush your account.

 

Hello

 

I have a little warning from Dropbox that im testing in a Unraid Machine.

 

In the log says to update the client within 5 days to continue using dropbox on the machine.

 

I guess it needs an update and i really need a Dropbox plugin / docker in this machine.

 

Any info?

I'll have a look. Because it seems the Dropbox client seems to have stopped updating.

Just pushed out an update of the Dropbox docker. Let me know if you still have issues.

No more warnings, thanks!

 

Anyway there is any possibility to see what the client is doing? Some infos like in the desktop version.

Well yes and no.

the client is the headless client. so there's really nothing to see.

On the other hand, it is possible to run some shell commands to see the client as it syncs. (but nothing more)

from the unRAID ssh/telnet shell

# docker exec -it -u nobody Dropbox /bin/bash -l
nobody@abc5221e:~/ $ cd Dropbox; dropbox.py <subcommand>

one of the commands is ls (or filestatus - don't remember which)

it will return the list of files as they are syncd.

 

Anything more monitoring is beyond the client (or my meager skills)

 

I noticed my Dropbox folder wasn't updating anymore and when I checked the logs it said that I was using an old version of the application.  The docker container indicates that it's the latest version, and the CA only shows the initial release for the container.

 

If there's a newer version how do I force an update of the docker image?

 

Thanks!

Yes, I see the problem. It seems the docker technology is preventing updates.

I happen to have a headless server installed with dropbox so I can see the upgrade issue.

I've upgraded the docker image now with dropbox 4.4.29, and will work on this over the next few days.

This is the latest that we can pull from the dropbox download links. but my headless server has 5.3.29 so I think auto upgrading is getting broken by the way a container works.

 

Hi again!

 

I tried in the past to run 2 dropbox dockers (me and wife) but without success.

After a few days (probably after modifying files through lan) they stop working.

 

So I ended up creating a VM just for dropbox!

 

I read that topic

http://lime-technology.com/forum/index.php?topic=48166

and I thought to give another try.

 

Fix? Depending on how your files are all set up in unRaid, you might want to take this approach:

force all files to be owned by "nobody".

all public access shares will work as normal.

all private access shares will use the user accounts to authorize access, but files will still be owned by "nobody"

To set this up: refer to: http://lime-technology.com/forum/index.php?topic=46401.msg461664#msg461664

 

What are the drawbacks of this?

I use public and private shares and connect with custom user and not root.

Unless you are using nfs mounts of the same shares and expect to have the files owned by the local user. Shouldn't be much. I've seen this scheme used in some commercial NAS OS and NAS distros. (Openfiler I believe)

 

Hi Ken-ji,

 

I keep having to change owner on the app folder from root to nobody:users and then re-link, every time I do an upgrade (I also chmod 777 on the app dir as the config dir is 777). Is this normal or have I set something up incorrectly?

 

Cheers,

Zan