Paul_Ber Posted July 11, 2017 Share Posted July 11, 2017 This computer is now linked to Dropbox. Welcome PaulCouldn't start Dropbox.This is usually because of a permissions error. Storing your home folder on a network share can also cause an error.Get more help at https://www.dropbox.com/c/help/permissions_errorPlease contact Dropbox support with the following info for help:/tmp/dropbox_errorVXA0a_.txt I started fresh, I still gets this error Quote Link to comment
Paul_Ber Posted July 11, 2017 Share Posted July 11, 2017 (edited) root@UNRAID:/mnt/cache/appdata/dropbox# ls -al total 0 drwxrwxrwx 1 nobody users 56 Jul 10 21:24 ./ drwxrwxrwx 1 nobody users 146 Jul 10 21:23 ../ drwx------ 1 nobody nogroup 184 Jul 10 21:24 .dropbox/ drwxr-xr-x 1 nobody nogroup 82 Jul 6 04:11 .dropbox-dist/ drwxr-xr-x 1 root root 0 Jul 10 21:23 Dropbox/ root@UNRAID:/mnt/cache/appdata/dropbox# Is that correct above? Permisions? Edited July 11, 2017 by Paul_Ber Quote Link to comment
Paul_Ber Posted July 12, 2017 Share Posted July 12, 2017 I gave up for now. It previously work for a long time, not sure what happened. I went with Dropbox on a Win10 VM tricking Dropbox to think it is local and not network for now. It seems the syncing needs a pause and then resume to actually sync. Quote Link to comment
ken-ji Posted July 12, 2017 Author Share Posted July 12, 2017 Sorry to hear you couldn't solve the permissions issue. I haven't had time to work on this, as the dropbox app it self operates rather mysteriously and keeps dropping the account authorization every unraid startup. When my personal life settles down I should be able to work on this some more. Quote Link to comment
tigburns Posted July 13, 2017 Share Posted July 13, 2017 On 7/11/2017 at 0:26 AM, Paul_Ber said: This computer is now linked to Dropbox. Welcome PaulCouldn't start Dropbox.This is usually because of a permissions error. Storing your home folder on a network share can also cause an error.Get more help at https://www.dropbox.com/c/help/permissions_errorPlease contact Dropbox support with the following info for help:/tmp/dropbox_errorVXA0a_.txt I started fresh, I still gets this error I am having the exact same issue, ken-ji. I completely deleted and re-installed the docker and am getting these errors. Your docker was working flawlessly for months prior to that. I still have backups of my old appdata files if they're of any help to you. I am going to try a VM for for now. Quote Link to comment
emmcee Posted July 14, 2017 Share Posted July 14, 2017 (edited) Same issue here too just recently. Just posting so I get updates when it's been fixed. Quote Couldn't start Dropbox.This is usually because of a permissions error. Storing your home folder on a network share can also cause an error.Get more help at https://www.dropbox.com/c/help/permissions_errorPlease contact Dropbox support with the following info for help:/tmp/dropbox_error1zwWQU.txt Edited July 14, 2017 by emmcee Quote Link to comment
gergtreble Posted July 16, 2017 Share Posted July 16, 2017 Also have this problem. Quote Link to comment
ken-ji Posted July 17, 2017 Author Share Posted July 17, 2017 Right, the permission issues is actually due to some missing libraries. The container is using Slackware as the base OS after all. I've pushed out the necessary change to correct the missing library issue, so the docker should work again. However, the account linking issue is still there AFAIK, and I"m still looking for a way to consistently replicate the problem so I can fix it. 1 Quote Link to comment
gergtreble Posted July 17, 2017 Share Posted July 17, 2017 Just forced an update and its working again now! Thanks a lot Ken-Ji. Quote Link to comment
emmcee Posted July 19, 2017 Share Posted July 19, 2017 Working for me too. Many thanks. My log is filling up with these warnings, but it doesn't seem to affect functionality. Quote WARNING:tornado.access:404 HEAD /blocks/1011599552/cKgg2BI2DF0A8scBPkyMlsCT5rj6AIN8yCkT1T4P5eg (172.17.0.1) 3.10ms Quote Link to comment
ken-ji Posted July 19, 2017 Author Share Posted July 19, 2017 That's a permission issue, but AFAIK with no way to isolate which file dropbox is having issues with. Quote Link to comment
Paul_Ber Posted July 19, 2017 Share Posted July 19, 2017 Back up and running. This time I deleted all traces of the docker. Made a new share for the Docker data folder that did not use the cache drive. I just had to map this new share in one of my other dockers. Quote Link to comment
ken-ji Posted July 19, 2017 Author Share Posted July 19, 2017 5 minutes ago, Paul_Ber said: Back up and running. This time I deleted all traces of the docker. Made a new share for the Docker data folder that did not use the cache drive. I just had to map this new share in one of my other dockers. Ok , but the Docker data folder should be cache only... or array only. Otherwise Dropbox will delete your files when the mover kicks in... Quote Link to comment
jrdnlc Posted July 20, 2017 Share Posted July 20, 2017 So is this docker only to have your dropbox files on your array or does it provide two way sync also? @ken-ji Quote Link to comment
ken-ji Posted July 20, 2017 Author Share Posted July 20, 2017 This works both ways. Just be careful to use a cache-only or share-only location with the Dropbox mount point. Quote Link to comment
Paul_Ber Posted July 23, 2017 Share Posted July 23, 2017 On 7/19/2017 at 1:24 PM, ken-ji said: Ok , but the Docker data folder should be cache only... or array only. Otherwise Dropbox will delete your files when the mover kicks in... Yes I made Dropbox data it's own share and disk only. Quote Link to comment
dstanley Posted September 19, 2017 Share Posted September 19, 2017 I have started getting the: "WARNING:tornado.access:404 HEAD /blocks/....." lines in my log file too - about 140 lines of them. Dropbox functionality seems to work still though - weird. To try 'fix' this I stopped the docker. Removed my local Dropbox share - recreated a new empty share. Started the docker on this new share and let it repopulate my files. These 'errors' returned in the log even in this situation. Another thing I noticed is that every time my docker is restarted I need to re-link it to my account - is that normal? Thanks for your docker work - I really appreciate it! Quote Link to comment
ken-ji Posted September 20, 2017 Author Share Posted September 20, 2017 Not sure what's causing the errors. What I do know is the linking issue and I have yet to figure out why its occurring, because AFAIK, docker wrongly assumes that the dropbox is now running on new hardware the server is restarted. the Docker link should survive container restarts, just not host (unRAID) restarts Quote Link to comment
dstanley Posted September 20, 2017 Share Posted September 20, 2017 Thanks Ken - I am truly a novice at anything Linux. I messed around with permissions in a terminal session and seem to have the error removed for now. I have noticed the following sequence of events but unsure if it is a problem. If I save a file to my Dropbox on my remote computer - it gets written to my Unraid share with permissions "nobody" "nogroup" If I use use something like Krusader to copy an Unraid local file to my Dropbox store the permissions are "nobody" "users" So I don't know if this is an issue or not - changing the group in the dockers advanced settings doesn't seem to affect the writing of this group permission difference. I noticed this issue after using the CA Backup/Restore plugin to make a copy of my Flash Drive to a Dropbox folder - both on the local Unraid server. Dwight Quote Link to comment
ORIMBELLI Posted January 14, 2018 Share Posted January 14, 2018 Using Dropbox Docker container [up to date version-while posting this] Noticing many weird behaviours: Worst of all: Share named "Dropbox" cannot be shared, is not published and not accessible by user. Shows up only if I connect as Guest but when clicking to list files connecting with AFP or SMB show and error."The operation can’t be completed because the original item for “Dropbox” can’t be found." Browsing with Krusader I can see all files synced, my own-created shares are working fine. Clicking on Port Mappings row "17500/tcp 192.168.1.201:17500" can't reach any site/page, not sure if this is indented for clicking... There is not "dumbo-mode" to login and start Dropbox from container, I've luckily clicked on Log "Up 31 minutes" and noticed a looping message about clicking on a link pointing to Dropbox.com... Checking with Krusader seems that permission are not passed correctly when set in Shares>Share Settings>AFP... Enclosing screenshot of Container page, pretty much default settings. Thanks for any ideas you Gang would like to share here. Mark [unRaid Server Plus 6.4.0] Quote Link to comment
ken-ji Posted January 14, 2018 Author Share Posted January 14, 2018 Well the default of the Docker is to run as the user nobody which has all the necessary permissions to be accessible by guest/(insecure share) I think the missing step is to actually define the Dropbox share user the Shares TAB of the unRAID Web UI Because if you didn't define it there, it will pickup/assume some settings that might not make any sense to your configuration (public share, etc) Do take note that by default a user share with a cache drive is a recipe for data loss, since any changes to your Dropbox files will result in the mover running at some point causing Dropbox to delete the underlying files. tl;dr the Dropbox share should be a cache-only or share-only. Do not try any of the other settings. The app running is the default one by Dropbox and has no "dumbo-mode" UI's . There's no site/page either - 17500 is needed for LAN syncing - Dropbox will happily send/receive updates from any of your Laptops/Desktops One known issue with Dropbox that I haven't solved is that upon restart of unRAID Dropbox thinks its a new PC and wants to be linked again. I haven't figured out what's causing this and have yet to get a controlled environment to test and try to fix with. 1 Quote Link to comment
ORIMBELLI Posted January 16, 2018 Share Posted January 16, 2018 hi ken-ji, thanks for your reply. I confirm my No-Cache-Disk for Dropbox share. Bug (?) Reporting : 1) WARNING:tornado.access:404 HEAD /blocks/1393998867/n74zf9taRF37OmKfCo1NgBnjrlijL1n9IqNzUPOOysA (172.17.0.1) 4230.70ms many lines like the above are shown in Log for: Dropbox. 2) I've experienced an hard time to setup different user for DB share, apparently I had to try many times to setup a different user, it was always sharing as Guest. After using your lovely Docker plugin here it is my features wish list: Easy way to setup user/permission in DB Docker (guest as default user is too "risky" imho: would you like your whole DB content exposed to all network users by default?) Button/link to authorise Docker at DB website: it is completely obscure for newbie like me to "discover" that I have to look for a log then to pickup a rapidly scrolling link to DB website... Thanks for your attention. \mark\ Quote Link to comment
Leliil Posted February 24, 2018 Share Posted February 24, 2018 It's sad that it's making mistakes and unsetting the account :/ At me the same problem as at people above ( tornado and logout after restart) Quote Link to comment
Snipe3000 Posted March 31, 2018 Share Posted March 31, 2018 Does anyone know if selective sync is built in yet? or do we still have to edit some files somewhere? 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.