Dropbox for R6 (x86 only)

WhoCares? wrote:
Dropbox Manager remembers the users you as the admin of the ReadyNAS started the Dropbox daemon for in the /etc/default/dropbox file.

OK, and that's how I have been managing them.

WhoCares? wrote:
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.

Which I deleted.

WhoCares? wrote:
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.

I see /data/.dropbox and /data/.dropbox-master (both of which I did delete), but there is no such /apps/.dropbox on my system.

I'm not sure if you meant to imply it, but after uninstalling and deleting files and re-installing, it did remember to start my user daemon but it was definitely not linked. I had to do that still. That's why I suspected /etc/default/dropbox. But I'll check to see what's left behind after uninstalling again this time.

WhoCares? wrote:
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.

Which is fair, except that I (from past experience in 4.2.x land) always delete the Dropbox folder(s) to avoid data loss when two existing archives try to sync. Had some nasty experiences with that in the past.

WhoCares? wrote:
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.

Well, I think I'm going another round with 1.0.4 re-install, since the dropbox daemon isn't dropping into the "downloading file list" status now, but it is getting stuck in the sync state at the same file count for hours and hours. And every single time I use the settings UI to stop/start (which I suspect is likely just running /etc/init.d/dropboxmanager), another defunct daemon is left hanging around.

btaroli wrote:

Well, I think I'm going another round with 1.0.4 re-install, since the dropbox daemon isn't dropping into the "downloading file list" status now, but it is getting stuck in the sync state at the same file count for hours and hours. And every single time I use the settings UI to stop/start (which I suspect is likely just running /etc/init.d/dropboxmanager), another defunct daemon is left hanging around.

Something is definitely *very* weird on your ReadyNAS. As much as I try, I can't reproduce *any* of the different behaviours of Dropbox that you're reporting. What version of ReadyNAS OS are you running? I'm using 6.1.6 and 6.1.7.
And sorry, I of course meant the /data/ folder, not /apps.

-Stefan

Running 6.1.7. And this is the very first addon I've ever had behave this strangely. I currently run TransmissionR6, Automatic, PLEX (many versions over time), DVBLink, ...

I was just wondering whether this addon was considered safe now to update to 6.2.0? It's been a few weeks since the email the dev sent warning us not to upgrade with no further communication on the issue. Seeing as the issue was that the entire webui becomes unusable for the entire Readynas I wanted to wait for confirmation. I'm running Dropbox Manager 3.0.3 currently.

As far as I know it is not. I decided to live without it for a bit and uninstalled it before upgrading. But I have not seen an announcement that the issues leading to problems have been addressed. I understand that this involves changes not only by the add-on developer but also Netgear. So this may not come quickly and could even involve needing to wait until a new ROS version is available, with any applicable fixes/changes.

Thanks. I might uninstall it for the time being then until I hear from the dev. I don't really need it but it's a nice addon to have just the same.

It's not working on the OS6.2.3 Beta's either. If you install the latest version of DB Manager on those firmwares, at least on my legacy Pro running 6.2.3-T1751 it will totally b0rk the HTTP and HTTP/S services for the entire NAS. Access is still possible to the NAS via HTTP/S for Frontview, but the indicators remain "off" in the settings area. HTTP never re-lights even after an uninstall, which does restore HTTP connectivity for everything else.

OS re-install doesn't completely fix it either. Only option to completely undo the damage is a Factory Default.

It's interesting you say that. I've been running the latest add-on version on 6.2.3 beta without apparent issues. The one thing I found that addressed some problems I was having with it continuing to die all the time was disabling the NAS'es AV function. That helped not only the stability of this addon, but also avoided the eventual problem I'd been experiencing installing or upgrading anything on the NAS (DBus timeouts).

Hmm. I have it (AV Plus) installed, but it's not enabled. However, as soon as I install Dropbox Manager it kills HTTP and all add-on links in the admin GUI are broken as well as their associated thumbnails. HTTP/S seems to be unaffected. But since it's using secure connections to download the core files, I think it may have something to do with the way it's injecting itself into Apache's config. I had a similar issue trying to follow a tutorial to set up a SSL certificate for phpmyadmin use, which failed in a very similar way with regards the admin GUI and anything referenced via regular HTTPS. This is using Firefox 35.01. Not tried it in IE.

I think an uninstall may be fully fixing the issue as HTTP access is restored. But the green bar above the service, and the associated checkmark in its settings, labelled: "HTTP Enabled" do not get restored to their prior state. This was after a factory default install with only SMB Plus add-on and AV-Plus add-on installed (but not enabled). The (scheduled) built-in AV scanner wasn't enabled either, and no bit-rot enabled on any shares. Snapshots set at default settings.

One thing I hadn't got around to doing was changing the HTTPS key host in settings from the default, to the name I issued the NAS during the setup wizard process. I simply forgot about it. This may (or may not) have a bearing on it.

...Of course, there may also be issues with the fact it had just started a full resync after I installed Dropbox. As I say this was a clean install of T1751 from the get-go. I had however downgraded from 6.3.3-T143 to the 6.2.3 beta (also because of this same issue) to see if it was an issue with compatibility with the newer 6.3.3 Betas.