Dropbox for R6 (x86 only)

Well, that's a little scary. I tried incrementally syncing a file to see how the daemon behaved. Other than seeing a small tick in it's CPU as I refreshed the settings page, nothing. So I went looking at the synced folders in my user homedir. All the /folders/ are there, and have appropriate user and group ownerships, and perms. BUT none of the files are there.

Any way I can offer some kind of diagnostic info here? This seems a pretty fundamental issue, but unless there's a smoking gun....

Are you sure the files have all uploaded to Dropbox? I think folders get uploaded first then files?

Where did you add the file you wanted to sync, to a client PC to then sync to the ReadyNAS or to the ReadyNAS to then sync to other devices?

If to the ReadyNAS did you add it using SMB? AFP? Something else?

(Chuckle) Oh yes, I'm sure the files are there. I have them synced to three different systems already and have access to them via my iPhone. You'll note that the image above clearly says it listed ~1400 files it should have synced.

For the record, I submit files to Dropbox from Mac, Linux, Windows and iOS. For the user homedir in question, I tend to use CIFS/SMB to access it from my Mac. But in this case, the Dropbox folder there was gone... So this was a completely fresh pull from the source. When I did the incremental test, I copied the file to my mac's synced folder and let it sync up to DB. It should then have synced back to other systems, including the NAS. Checking for that -- vid SMB and SSH -- is wheni found none of the files was actually present (on the NAS).

Hope this helps clarify.

btaroli wrote:
So I figured I'd start fresh, since previously I had no guide for what to expect when starting this thing. So I yanked out all Dropbox references from my user home dir, returned /etc/default/dropbox to it's virgin null status, and rebooted the NAS (no amount of killing was going to get rid of the original zombie/defunct process).

But you didn't remove the add-on and didn't make any changes/deleted the Dropbox references that were installed in your primary storage location (presumably /data)?

btaroli wrote:
I should point out that trying to apply either the newer stable or testing builds results in an error. No logging on that either?

Would have been nice to see the actual error message. But no, no logging on that either ;) But to give you a better understanding let me try to explain what is happening and also why I can't fix this.

On initial install, Dropbox Manager wil try to download the Dropbox binaries from the generic "stable" link provided by Dropbox, e.g. from here https://www.dropbox.com/download?plat=lnx.x86_64
As you can see this is an unversioned link and it *should* point to the latest stable release. Unfortunately Dropbox isn't very good at keeping these links current, that's why in most of the cases Dropbox Manager will install a version that is older than the one Dropbox Manager later on reports as being the current "stable" version.

Now, how does Dropbox Manager determine the current stable and testing versions? By looking at the official Dropbox RSS feed which basically offers the same information as their Release Notes page. To access these relelases directly, you need to use a special URL which I currently can't tell you for I'm at work and have no access to my dev environment at home. Anyway, as is the case with the stable releases Dropbox also is a bit slow when putting newer releases into the "direct download directory". So what happened in your case most likely is that while 2.6.31 was announced on the releases page as well as the RSS feed there wasn't any real downloadable version available in the direct downloads directory.

Since the actual installation of newer versions is done using a bash script it is very hard to find out why exactly the download failed (which is the main reason why it would fail at all). Other reasons for a failed download may of course be:
- wrong or no DNS settings
- no active internet connection
- full /tmp directory on your NAS
- (whole hell of other reasons)

But yes, trying to do better error detection and maybe providing more elaborate feedback to the user is on my todo list.

btaroli wrote:
Having cleared the config, starting the daemon for my user required linking again. No biggie. Once done the display changed to what I had previously seen. First it retrieved the file list and then began counting down as it syncs. I've just checked again and it says retrieving file list again. Odd but I'll check it again in a few mins before posting this.

What you're seeing is what Dropbox writes into it's messaging socket. Of course Dropbox will check (and thus download) the file list on a regular basis since that's how it determines whether there have been some changes to it's master source. So chances are that if you just hit "refresh" often enough, you'll see the message appear and disappear again.

btaroli wrote:
Well, that's a little scary. I tried incrementally syncing a file to see how the daemon behaved.

What exactly do you mean by "incrementally syncing"?

btaroli wrote:
Other than seeing a small tick in it's CPU as I refreshed the settings page, nothing. So I went looking at the synced folders in my user homedir. All the /folders/ are there, and have appropriate user and group ownerships, and perms. BUT none of the files are there.

Well, I've got Dropbox Manager running on five different ReadyNAS systems, linked to different Dropbox accounts, some running "stand-alone", some in parallel and all are running perfectly. If they hadn't, I wouldn't have released the app. So I currently have no idea what may have gone wrong with your installation except maybe an improper "manual cleanup" that left some older configs on the system. In any case, if the folders are there, sync should automatically run over the LAN link and the files should appear. Depending on the size of your Dropbox you should be able to at least monitor the progress of an initial sync by refreshing the status page after linking a Dropbox.

Which reminds me: what version of the Dropbox Manager app are you using? Not that it would matter much for the core functionality hasn't changed. I just want to make sure we're talking about the same version here. But in the end I think I'll need to have a look at your system to see what is going on there.

-Stefan

WhoCares? wrote:

btaroli wrote: ... I yanked out all Dropbox references from my user home dir, returned /etc/default/dropbox to it's virgin null status, and rebooted the NAS (no amount of killing was going to get rid of the original zombie/defunct process). But you didn't remove the add-on and didn't make any changes/deleted the Dropbox references that were installed in your primary storage location (presumably /data)?

Well, if you mean /data/Dropbox, for the "admin" setup I presume, then no. I never started that one so there's nothing at all in there, even now.

# cd /data/Dropbox/
# ls -lA
total 0

The bits I removed from the homedir where I *was* running it were: .dropbox, Dropbox, and .dropbox-dist

WhoCares? wrote:

btaroli wrote: I should point out that trying to apply either the newer stable or testing builds results in an error. No logging on that either? Would have been nice to see the actual error message. But no, no logging on that either ;) But to give you a better understanding let me try to explain what is happening and also why I can't fix this. On initial install, Dropbox Manager wil try to download the Dropbox binaries from the generic "stable" link provided by Dropbox, e.g. from here https://www.dropbox.com/download?plat=lnx.x86_64 As you can see this is an unversioned link and it *should* point to the latest stable release. Unfortunately Dropbox isn't very good at keeping these links current, that's why in most of the cases Dropbox Manager will install a version that is older than the one Dropbox Manager later on reports as being the current "stable" version.

Well, I did try a simple wget on this and got:

# wget https://www.dropbox.com/download?plat=lnx.x86_64
--2014-04-23 12:35:30--  https://www.dropbox.com/download?plat=lnx.x86_64
Resolving www.dropbox.com (www.dropbox.com)... 108.160.165.20
Connecting to www.dropbox.com (www.dropbox.com)|108.160.165.20|:443... connected.
ERROR: The certificate of ‘www.dropbox.com’ is not trusted.
ERROR: The certificate of ‘www.dropbox.com’ hasn't got a known issuer.

OK... this time with --no-check-cert

# wget https://www.dropbox.com/download?plat=lnx.x86_64 --no-check-cert
--2014-04-23 12:35:49--  https://www.dropbox.com/download?plat=lnx.x86_64
Resolving www.dropbox.com (www.dropbox.com)... 108.160.165.20
Connecting to www.dropbox.com (www.dropbox.com)|108.160.165.20|:443... connected.
WARNING: The certificate of ‘www.dropbox.com’ is not trusted.
WARNING: The certificate of ‘www.dropbox.com’ hasn't got a known issuer.
HTTP request sent, awaiting response... 302 FOUND
Location: https://dl-web.dropbox.com/u/17/dropbox-lnx.x86_64-2.6.31.tar.gz [following]
--2014-04-23 12:35:49--  https://dl-web.dropbox.com/u/17/dropbox-lnx.x86_64-2.6.31.tar.gz
Resolving dl-web.dropbox.com (dl-web.dropbox.com)... 54.243.190.36
Connecting to dl-web.dropbox.com (dl-web.dropbox.com)|54.243.190.36|:443... connected.
WARNING: The certificate of ‘dl-web.dropbox.com’ is not trusted.
WARNING: The certificate of ‘dl-web.dropbox.com’ hasn't got a known issuer.
HTTP request sent, awaiting response... 302 FOUND
Location: https://dl.dropboxusercontent.com/u/17/dropbox-lnx.x86_64-2.6.31.tar.gz [following]
--2014-04-23 12:35:50--  https://dl.dropboxusercontent.com/u/17/dropbox-lnx.x86_64-2.6.31.tar.gz
Resolving dl.dropboxusercontent.com (dl.dropboxusercontent.com)... 50.19.234.162, 54.243.74.238, 54.243.241.219, ...
Connecting to dl.dropboxusercontent.com (dl.dropboxusercontent.com)|50.19.234.162|:443... connected.
WARNING: The certificate of ‘dl.dropboxusercontent.com’ is not trusted.
WARNING: The certificate of ‘dl.dropboxusercontent.com’ hasn't got a known issuer.
HTTP request sent, awaiting response... 200 OK
Length: 24380314 (23M) [application/octet-stream]
Saving to: ‘download?plat=lnx.x86_64’

100%[==========================================================>] 24,380,314  1.95MB/s   in 14s    

2014-04-23 12:36:05 (1.72 MB/s) - ‘download?plat=lnx.x86_64’ saved [24380314/24380314]

So at this moment, at least, it is pulling 2.6.31 when accessed.

WhoCares? wrote:

...To access these relelases directly, you need to use a special URL which I currently can't tell you for I'm at work and have no access to my dev environment at home. Anyway, as is the case with the stable releases Dropbox also is a bit slow when putting newer releases into the "direct download directory". So what happened in your case most likely is that while 2.6.31 was announced on the releases page as well as the RSS feed there wasn't any real downloadable version available in the direct downloads directory. Since the actual installation of newer versions is done using a bash script it is very hard to find out why exactly the download failed (which is the main reason why it would fail at all).

OK. I see install_dbx.sh and that indicates the direct URL is (forgiving var reference): https://dl-web.dropbox.com/u/17/dropbox-lnx.x86_64-${DBX_VERSION}.tar.gz

Maybe I'll step through the bits of the script and see if I can isolate that behavior, to determine if it's something local. But I can accept that there may be lag here, knowing how often DB puts out builds.

WhoCares? wrote:
btaroli wrote: ... I've just checked again and it says retrieving file list again. Odd but I'll check it again in a few mins before posting this. What you're seeing is what Dropbox writes into it's messaging socket. ... So chances are that if you just hit "refresh" often enough, you'll see the message appear and disappear again.

Figured it might be something like that... but never hurts to ask. :)

WhoCares? wrote:
btaroli wrote: Well, that's a little scary. I tried incrementally syncing a file to see how the daemon behaved. What exactly do you mean by "incrementally syncing"?

Added a file to the dropbox, to see if the NAS picked it up and downloaded it.

WhoCares? wrote:

... So I currently have no idea what may have gone wrong with your installation except maybe an improper "manual cleanup" that left some older configs on the system. In any case, if the folders are there, sync should automatically run over the LAN link and the files should appear. Depending on the size of your Dropbox you should be able to at least monitor the progress of an initial sync by refreshing the status page after linking a Dropbox.

Well, I guess I'll try completely removing it and re-adding. It sure did /seem/ to be doing the right thing. I saw the file count tick downward as I refreshed the page. So I was pretty surprised to see only sub-folders there afterward.

WhoCares? wrote:
Which reminds me: what version of the Dropbox Manager app are you using?

The version the page gave me when I paid... 1.0.1

Just noting things as I proceed with reinstall and setup.

1) Stopping

Clicked Stop All (twice) and got confirmation that all were stopped. But they weren't. The daemon for my user was still running and reflected as such in the settings page.

Then clicked stop on my specific user, and it did stop. Well, it left a defunct process sitting in the list. But I'll count that as stopped for my purposes.

2) Uninstall

Ugh... uninstall killed ROS web UI again. :( Initiated reboot via ssh to recover. The last time this happened, I recall I'd installed while the defunct process was there. Perhaps that's what's gumming things up. Though I'm not sure what's causing it to not to properly die.

/apps/dropboxmanager subfolder was gone, Dropbox share still present (removed). Also found .dropbox, .dropbox-dist, and Dropbox/ still in my user homedir... removed those too.

3) Install

Odd note. The Add-on reported itself as 1.0.1 in the ROS UI but the package file is dropboxmanager_1.0.2_amd64.deb. Hmm...?

Upload installation succeeded. Add-on still reports itself as 1.0.1.

4) Configure

Upon launching settings, I see it does now have 2.6.31 -- so that may have been the aforementioned lag for the direct download link.

So I click start next to my user name. I see the daemon process start and get success message in settings UI.

Clicked "link" button and successfully linked. See daemon getting busy and status currently "downloading file list".

Refreshing after a few moment shows 1400+ files to retrieve, similar as I saw last time. So I'll check in on it periodically and let it do it's thing. Strangely, the top display on the NAS shows the daemon using almost no CPU though... but in the settings UI I see the count slowly going backward, so I'll go away and let it do it's thing...

No, something's definitely wrong in the sync. In two minutes I went from 1389 files and 25 minutes remaining to "downloading file list". :(

I notice that each of the folders it created has a .dropbox file in it and there is a .dropbox.cache folder in the base folder, which a number of files in it. But that's it.

btaroli wrote:
Well, if you mean /data/Dropbox, for the "admin" setup I presume, then no. I never started that one so there's nothing at all in there, even now.

No, I meant /data/.dropbox (but not /data/.dropbox-dist and of course not /data/Dropbox)

btaroli wrote:

WhoCares? wrote: btaroli wrote: I should point out that trying to apply either the newer stable or testing builds results in an error. No logging on that either? Would have been nice to see the actual error message. But no, no logging on that either ;) But to give you a better understanding let me try to explain what is happening and also why I can't fix this. On initial install, Dropbox Manager wil try to download the Dropbox binaries from the generic "stable" link provided by Dropbox, e.g. from here https://www.dropbox.com/download?plat=lnx.x86_64 As you can see this is an unversioned link and it *should* point to the latest stable release. Unfortunately Dropbox isn't very good at keeping these links current, that's why in most of the cases Dropbox Manager will install a version that is older than the one Dropbox Manager later on reports as being the current "stable" version. Well, I did try a simple wget on this and got: [...] 2014-04-23 12:36:05 (1.72 MB/s) - ‘download?plat=lnx.x86_64’ saved [24380314/24380314][/code] So at this moment, at least, it is pulling 2.6.31 when accessed.

Fine, so they finally updated the generic link target. But I'm not sure I understand the relevance here.

btaroli wrote:
WhoCares? wrote: Which reminds me: what version of the Dropbox Manager app are you using? The version the page gave me when I paid... 1.0.1

Would be nice if you could log in again and download 1.0.4 from the "My Account" page. I'm pretty sure I fixed something for downloading updates in 1.0.2 or 1.0.3.

-Stefan

btaroli wrote:
No, something's definitely wrong in the sync. In two minutes I went from 1389 files and 25 minutes remaining to "downloading file list". :( I notice that each of the folders it created has a .dropbox file in it and there is a .dropbox.cache folder in the base folder, which a number of files in it. But that's it.

I'm just guessing here but is there a chance that when you tried to install the app using dpkg Dropbox was started under the root account, in other words: are there any .dropbox* directories in /root? My general approach is that "the software is right" so I assume that the files it says it has either downloaded or verified are *somewhere* on your ReadyNAS. The low CPU usage also indicates that Dropbox is just verifying instead of downloading (ok, depending on the size of the 1400+ files it could also just do a LAN copy of small files but a verify operation seems more likely to me). So maybe running

find / -name "<name of a file known to be in your dropbox>"

would shed some light as to where Dropbox has actually put your files (assuming it really did, of course).

-Stefan

Nope, nothing in /root. Despite that, it was odd that /folders/ were showing up in my user homedir, but not files. :) Would it put them different places? ;)

Anywho, I downloaded 1.0.4 from the site, removed the 1.0.2 (1.0.1?) install. I did have to reboot the NAS to get back into the admin UI afterward. Noticed the same pattern of folders left behind as before. I did additionally check /data and found .dropbox and .dropbox-master. Removed those too.

Upon installing 1.0.4, it seemed to magically remember that my user was configured. Given I'd previously wiped out the list in /etc/default/dropbox when doing earlier uninstall, I'm left to imagine that the file was left there after doing this last uninstall? Not sure.

The /good/ news is that it looks like it's actually downloading files this time. The count hasn't gone down in a bit, so I suspect it's got a big file downloading now (I've got about 3GB in there). But it's still actually running and I can observe files it's successfully retrieved. Much improved.

Am I curious enough to try and install the old version to verify if that was the issue? Not at this moment, but ask me later. ;)

Also, is there a way to get notified when new builds of the add-on are available?

btaroli wrote:
Nope, nothing in /root. Despite that, it was odd that /folders/ were showing up in my user homedir, but not files. :) Would it put them different places? ;)

I agree but then I have no insight into the internals of Dropbox so my guess at what happened is as good as anyone's ;)

btaroli wrote:
Upon installing 1.0.4, it seemed to magically remember that my user was configured. Given I'd previously wiped out the list in /etc/default/dropbox when doing earlier uninstall, I'm left to imagine that the file was left there after doing this last uninstall? Not sure.

That's two totally different things. Dropbox Manager remembers the users you as the admin of the ReadyNAS started the Dropbox daemon for in the /etc/default/dropbox file. Dropbox itself however remembers it's state for every user in an encrypted database it puts into the .dropbox directory below the user's home dir. Or into /apps/.dropbox for the admin user. Since you didn't wipe this dir on your latest try Dropbox of course maintained stated and remembered that the Dropbox was already linked. The Dropbox Manager app will *never* wipe either the Dropbox folder or the .dropbox info structure. This is to make sure that a users doesn't accidentally removes his files.

btaroli wrote:
Am I curious enough to try and install the old version to verify if that was the issue? Not at this moment, but ask me later. ;)

Well, you can try that if you want to. But I don't think that there's any real benefit in doing so, since the old version is no longer available to users anyway.

btaroli wrote:
Also, is there a way to get notified when new builds of the add-on are available?

I've been thinking about this but haven't yet come to a solution that's good enough for me. I could try using some sort of mailing list but then I don't want to spam users. I could try to check directly from the ReadyNAS but that would require a working internet connection on the NAS as well as a alert email address being set (for I would want to notify the admin and not each and any user of the NAS). Or I could try to make a check from within the different web interfaces. This would possibly work for Dropbox where the web interface was written by me, but wouldn't work for other apps/add-ons where there is no real custom interface. And it also would require an active internet connection of course. To sum it up I find it a bit disappointing that NETGEAR with ROS6 stripped the update notification system that was integrated into ROS4 and ROS5.

-Stefan

P.S.: The version you were using before actually was 1.0.2. The thing there is that NETGEAR doesn't determine the version number from the file name automatically but instead requires the developer to manually change that number in the config.xml file - which I obviously forgot for 1.0.2.