ken-ji Posted February 26, 2016 Author Share Posted February 26, 2016 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. Quote Link to comment
webrob123 Posted February 27, 2016 Share Posted February 27, 2016 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? Quote Link to comment
ken-ji Posted February 27, 2016 Author Share Posted February 27, 2016 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. Quote Link to comment
jnheinz Posted February 28, 2016 Share Posted February 28, 2016 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. Quote Link to comment
mattcoughlin Posted March 8, 2016 Share Posted March 8, 2016 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. Quote Link to comment
Snake575 Posted March 27, 2016 Share Posted March 27, 2016 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? Quote Link to comment
ken-ji Posted March 27, 2016 Author Share Posted March 27, 2016 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) Quote Link to comment
djgizmo Posted April 4, 2016 Share Posted April 4, 2016 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? Quote Link to comment
ken-ji Posted April 5, 2016 Author Share Posted April 5, 2016 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. Quote Link to comment
djgizmo Posted April 5, 2016 Share Posted April 5, 2016 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? Quote Link to comment
djgizmo Posted April 5, 2016 Share Posted April 5, 2016 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? Quote Link to comment
ken-ji Posted April 5, 2016 Author Share Posted April 5, 2016 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? Quote Link to comment
djgizmo Posted April 5, 2016 Share Posted April 5, 2016 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. Quote Link to comment
djgizmo Posted May 12, 2016 Share Posted May 12, 2016 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? Quote Link to comment
ken-ji Posted May 14, 2016 Author Share Posted May 14, 2016 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. Quote Link to comment
exico Posted May 19, 2016 Share Posted May 19, 2016 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? Quote Link to comment
ken-ji Posted May 19, 2016 Author Share Posted May 19, 2016 I'll have a look. Because it seems the Dropbox client seems to have stopped updating. Quote Link to comment
ken-ji Posted May 21, 2016 Author Share Posted May 21, 2016 Just pushed out an update of the Dropbox docker. Let me know if you still have issues. Quote Link to comment
exico Posted May 21, 2016 Share Posted May 21, 2016 No more warnings, thanks! Anyway there is any possibility to see what the client is doing? Some infos like in the desktop version. Quote Link to comment
ken-ji Posted May 22, 2016 Author Share Posted May 22, 2016 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) Quote Link to comment
FrackinFrog Posted June 14, 2016 Share Posted June 14, 2016 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! Quote Link to comment
ken-ji Posted June 14, 2016 Author Share Posted June 14, 2016 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. Quote Link to comment
karateo Posted June 19, 2016 Share Posted June 19, 2016 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. Quote Link to comment
ken-ji Posted June 19, 2016 Author Share Posted June 19, 2016 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) Quote Link to comment
Zan Posted June 27, 2016 Share Posted June 27, 2016 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 Quote Link to comment
Recommended Posts
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.