New FW still does not fix the passwd reset

This is officially the worst device security wise EVER.

What was DRI thinking when developing something that resets passwords when their software has a bug or the device reboots/has an issue.
Whose brilliant idea was it to make it root - root, put a sticker on it with red letters, hell, broadcast it via the connection itself.

I waited for, what, 6 months??? for new FW to fix this.

Last Drobo I’m buying, not even going to bother trying to find a solution, I’ll just turn off all WAN connection, ty DR for this wonderful piece of worthless **** and stop advertising it as more than a NAS which it isn’t.

Graviton signing out of this forum, for good?

If security is a big issue for you then you have a couple of options:

  1. Make sure that the drobo isn’t accessible outside of your LAN. Being that most people will have this behind a NAT and will need to explicitly set up port forwarding to reach it from outside of their LAN it’s not a huge issue for the vast majority of people.
  2. If it is an issue then just disable dropbear from the drobo admin interface and make sure that the droboadmin interface is buried behind an htpasswd.

Sure, it’s a pain in the ass and it would be best if Drobo was able to make this work better for people like us, but I don’t see how anyone can get so angry about this. If you wanted this to be everything you dreamed you probably would have done a lot better to just have built your own box. Don’t you think so?

This pisses me off. Several of us has opened cases about this. DRI doesn’t seem to care about fixing their sloppy programming. Complaining on here doesn’t seem to help since this is a closed forum. I am starting to think that everytime DRI advertises the Drobo on Facebook, to add my questions there about when they will fix this problem. I wonder if that will help?

WOW! I think it’s just that DRI advertised this box as THE joe average solution that can be utilized in so many different ways. The performance they advertise is achievable in SOME cases, by CLI familiar programmer/network engineer types, or at least a person who has countless hours of free time to play with all the info found in these forums. NOT USER FRIENDLY. Again, I would never have spent the $ for this product, had I had access to these forums before hand. I am a photographer, not an IT pro. The marketing tactics used by DRI are certainly deceptive at best.
@rapier1: Thank you for all your work and the time you take to post and help people in these forums; however, I don’t understand how you could make the statement: “Sure, it’s a pain in the booty and it would be best if Drobo was able to make this work better for people like us, but I don’t see how anyone can get so angry about this. If you wanted this to be everything you dreamed you probably would have done a lot better to just have built your own box. Don’t you think so?”

It doesn’t sound like anyone here is asking for any more than DRI promised us. I’m pissed too!

I don’t understand. There is a script called “root_passwd” inside the dropbear droboapp folder that does exactly that: it allows you to permanently change the root password.

If you are so inclined, you can study the script and figure out where the info is hidden, but there is no need to do so. Just run the script and change the password to your heart’s content.

This is not new, btw. It has been there since I installed the dropbear app for the first time. I have changed the root password on mine since about two weeks after I bought it, once I saw the script.

EDIT: And for crying out loud, can we please calling this a “bug”? The Drobo does exactly what it has been programmed to do, which is to restore the root password unless it has been properly updated in all the required files, or by using the aforementioned script. We might argue whether or not this is a good choice, but in any case it is not a bug. [hr]

So, let me get this straight: you want the Drobo to magically fix Apple’s Airport Express sh***y network performance? To magically fix the ret***ed choices that Microsoft made for their TCP/IP stack? To somehow fix the cra**y Mac hardware that does not support Jumbo Frames? Have you noticed that besides the lack of a Linux version of the Drobo Dashboard, you hardly see any Linux users complaining? (Disclaimer, Mac user here)

Pray tell, how do you think that a box that is supposed to hold a few disks inside and offer a Linux shell can possibly guess and fix the configuration of all the network hardware out there? I know a few people that made a career out of that kind of knowledge.

Post after post I see people complaining about the performance of their Drobos, in particular the FS. In every case so far, where the poster has actually bothered to see what was going on, the fault laid either on bad network gear (even god**mn network cables!) or computer misconfiguration (with the odd bad drive here and there).

People like rapier1 and myself have been trying to dissect the FS’s performance down to the bare components (network here, storage here), and guess what: it is not perfect, but clearly it is not as bad as people seem to think.

So, maybe I am more of a nerd than other people in this forum, but please, can we please check the known-to-be-bad stuff before bashing the Drobos? Seriously, if you hear hoofs in New York, think horses and not zebras…

Disclaimer: I’m not saying Drobos are perfect or anything. Is just that the kind of complaints that keep constantly showing up in these forums are starting to get old. Maybe we should put an FAQ up or something.

@ ricardo butt out dickhead! I wasn’t talking to you!

you were the first person on here to jump down my throat for not blindly falling into line with all the DROBO propaganda floating around these forums. I am a former carpenter, and now a photographer. I am the guy the DROBO is marketed to, the average user. I am no IT pro by any means, and your condescending attitude towards us “regular users” is really getting old. I imagine tweaking your network and your DROBO via command line is something you could do in your sleep. Not me however; I find this stuff really hard, tedious and extremely time consuming. DRI hid this forum from me until after I bought and registered their product.
I’ll say it again: We’re not all programing geniuses like you, but we’re not stupid either, we simply feel duped by DRI. Where else should we express this? maybe to the BBB?

And just for the record, I read all the posts in this forum, and I try the different tweaks and mods that I feel comfortable with.

I am using brand new STP CAT 6 cabling at all points throughout my network.

I have switched out my Airport Extreme for a Netgear GS108T as is mentioned in several posts.

??? " Maybe we should put up a FAQ" ???

Maybe DRI should just get open and honest and open this forum to the general public!
Sorry if I’m not a big DRI fanboy like you, ricardo but I don’t like to deal with people who are deceptive or sneaky.

Again, you flamed the hell out of me on my first post to this forum. Please, unless I address you specifically, STAY OUT OF MY BUSINESS!

[quote]Disclaimer: I’m not saying Drobos are perfect or anything. Is just that the kind of complaints that keep constantly showing up in these forums are starting to get old. Maybe we should put an FAQ up or something.

You might wonder why complaints “keep constantly showing up” in the first place.

Have you considered it is because Data Robotics is using false advertising when they say what the devices are capable off?
Or is it because they are hiding this forum (with details of the current issues with their devices) from prospective customers?

I have several systems in my LAN, including multiple Linux boxes, Windows etc etc, I am a certified MS professional and have been working in IT a long time with over 25 years of computer knowledge behind me, hell, Linux for me was back in the 90’s …

I know about the scripts that are running etc etc.

My issue is that the Dashboard can only be accessed correctly from ONE SYSTEM, all the other systems say I am connected as admin but the minute I try to do something it locks up and the accounts/passwords get reset to root - root AND even when I don’t do this … the moment it starts doing stuff or rebooting it looses my settings … sooooo … I don’t know where you have been living but this is not what I’d expect from something that is advertised as the perfect simple solution, I doubt they can even make, I forgot the name, that WAN sharing/backup solution, work like it should as long as the FS fails to keep his settings.

So the issues I have been having from the beginning ARE NOT Apps but the DROBO software/OS.

This means that to be sure that my WAN access is not compromised I have to check on a regular basis that the paswwd has not been reset, if you find this normal … well, software tester or not, but then you might wanna check with someone whom has a medical degree.

But anyheeuw, signing out again.

I apologize if it seemed like I was doubting your expertise, graviton.

Fair enough. This seems to be a different problem than what I was thinking of. My understanding is that if you just try to use the ‘passwd’ command on the shell, it won’t (permanently) change the password for you. You have to use the ‘root_passwd’ script in the dropbear folder.

Would you be so kind to post a step-by-step procedure so that we can also try to reproduce what is happening to you? I haven’t created any additional accounts on my Drobo because I map everything to the ‘nobody’ account, so I never had a problem of disappearing accounts.

I’m pretty sure that if other people start reproducing the same behavior as you do, DRI will have no choice but to fix it.

Again, could you please elaborate on this? “doing stuff” is kind of hard to reproduce. Maybe just by trying it ourselves we can not only push DRI into fixing it, but in the mean time find a way to work around it.

I would like to clarify that I am in no way a DRI apologist, but I do believe that we ought to give to Ceasar what’s Ceasar’s.

Here is a list of some serious problems that the FS has:
[]The power supply is noisy. That one has been confirmed by many in here, and DRI has taken steps to replace the power supply of anyone that bothers to open a support ticket.
]The fan is too loud when the FS gets hot. This one has not yet been addressed by DRI, and I do not think that anything can be done short of manually replacing it yourself.
[]The Drobo Dashboard is, well, shouldn’t be. There is a ‘petition’ going on for an embedded web-version of it that would reside on the Drobo itself. There are so many horror stories about the Dashboard that it is not even funny. What is funny though, is that after some initial setup there is absolutely no need for that thing. I have it installed in just one machine, so that I can have a look every once in a while to check for firmware updates. Under no circumstances it should be used for actually mounting the shares. That only seems to cause trouble.
]The CPU used in the FS might be a little bit too weak to actually push a Gbps on the network. We still need some confirmation on those preliminary findings, but it wouldn’t surprise me that this turns out to be the case.
And, of course, there have been cases of DOA devices, but that happens to everyone.

What I do not understand is people complaining that a device that consumes only 12 W when idle should be able to transcode 1080p media from Fuppes in realtime, and god forbid the 400 MHz ARMv9 processor (slower than an iPhone 3G, if I remember correctly) chokes on it and stutters. Of course, you can blame DRI for saying that a Drobo can host a Fuppes server, but the fact of the matter is that hosting the server is not the problem. The problem is expecting that a NAS (any NAS, for that matter) can perform CPU intensive stuff that would make most Core 2 Duo-generation processors take a severe beating.

The other common complaint is about network performance. Rapier1 has done an excellent job basically proving that the FS can push upwards of 800 Mbps (or 100 MBps - which is basically faster than most SATA drives, and enough to give older SSDs a run for their money). I have looked at the storage performance, and although it is not as fast as the network side (tops at 40 MBps in the worst case), it is still faster than most cheap USB2 flash drives. Storage results have been confirmed by rapier1. In summary: there is always the possibility that your Drobo has a problem, but as far as we can tell at the moment, if you have throughput problems odds are it is not the fault of the Drobo.

Now, here is the place for a disclaimer. We have had some people comparing Drobos to the Synology devices. That is a shame, because you simply can’t compare the technologies. RAID is a well established technology that has been implemented, re-implemented and fine-tuned for decades now, as part of the Linux kernel. BeyondRAID is proprietary technology, which only gets developed by DRI (meaning many man-hours less than Linux). Not only that, BeyondRAID seems to be quite more complex than RAID (have yet to read the patent myself, so don’t take my word for it). However, BeyondRAID offers a simple upgrade path, which RAID does not. As of today it is a compromise: simpler upgrade path versus increased throughput. Maybe in the future BeyondRAID will become faster than RAID, but I wouldn’t be on it.

Finally, there are a lot of complaints about setting up access to the Drobo from the internet. It usually falls within these categories:
[]DroboApps suck, they are too complicated.
]Having to change my router configuration (port forwarding, etc) sucks, it is too complicated.

I can sympathize with the request for a simple way to configure your Drobo to access it from the internet. However, people have to understand that this stuff is hard for any device. Setting up FTP on your Drobo is not any harder than to set it up on your PC. Changing the router configuration for the Drobo is not any harder than to change it for any other PC-hosted service.

And unfortunately, we can’t make it any easier. There are just too many types of network switches, routers and ISPs to make this thing absolutely transparent. Apps like Skype make it simple because they have been built from the ground up to support this kind of network topology. Old protocols like FTP have not. They simply have not been built to be easy on today’s networks.

Let’s take FTP as an example. FTP is 26 years old. Back in those days the word “firewall” was stuff of academic papers. Even NAT (Network Address Translation) was invented 9 years later. Today, every single home router performs NAT. And NAT breaks FTP, badly. Luckily, router manufacturers have given us workarounds to kind of make all of this old stuff work with the new way networks are laid out nowadays. But that is all it is: workarounds.

Is there a better option? To be quite honest: no. Unless you are willing to pay for it. The free options to access your Drobo from the internet are basically:
[]Install some traditional server software (FTP, HTTP, SCP), configure it and the router to forward requests to it.
]Configure some device (your router, a PC in your LAN, even the Drobo itself) to act as a VPN server. Connect to the VPN and browse the Drobo like you would in your LAN.
And that is it. If you are willing to pay, then you can:
[]Configure your FS to sync the data you want to some cloud storage provider (Amazon S3 how-to). Pros: you control it, anyone can be given access without special software, Con: you have to do it yourself.
]Install the Oxygen Cloud droboapp. Pros: Seems to have zero effort once installed, and very little to actually get it installed, Con: requires the Oxygen client to access the data.

In the end, I think it comes down to expectations. My FS does reliable storage and does it very well. That is enough for me. The fact that I can tweak it and run all kinds of extra software on it, is somewhat of a bonus.

The Drobos CPU is only 400MHz??? Whow. My Synology DS1511+ has a 1.8GHz Dual Core CPU. And the difference in cost for me was only 80 euros!

Take a look at Synology Hybrid RAID, which is very similar to BeyondRAID. Very easy to use, expand, etc.

To be honest, I don’t really know. I have looked on the web for the info and couldn’t find a reliable source. The closest I got to was this page from ARM indicating 470 MHz.

Here is the output of /proc/cpuinfo:

Processor	: ARM926EJ-S rev 0 (v5l)
BogoMIPS	: 799.53
Features	: swp half thumb fastmult vfp edsp 
CPU implementer	: 0x41
CPU architecture: 5TE
CPU variant	: 0x1
CPU part	: 0x926
CPU revision	: 0
Cache type	: write-back
Cache clean	: cp15 c7 ops
Cache lockdown	: format C
Cache format	: Harvard
I size		: 32768
I assoc		: 4
I line length	: 32
I sets		: 256
D size		: 32768
D assoc		: 4
D line length	: 32
D sets		: 256

Hardware	: Feroceon-MV78XX0
Revision	: 0000
Serial		: 0000000000000000

I could be wrong though. An official word from DRI would be nice.

Thanks for the heads up. I did not know about that model. It is great to see some fierce competition on this area. Maybe this will encourage DRI to release the DroboFS2.

I haven’t found any hard data on the kind of CPU running on the DS1511+, but the fact alone that it has 1 GB of RAM will make it run circles around the FS due to better caching. I would love to run iozone on one of those puppies.

I have read their wiki page on the Hybrid RAID, and it is a bit light on details. My first impression is that it creates several smaller RAID partitions and somehow strings them together. Also, the procedure to expand the RAID space is not nearly as friendly as BeyondRAID. One of the things that always amazed me on the Drobo marketing videos was the fact that they would juggle disks in and out while a client PC would keep playing a video without skipping a frame. They get cookie points for using non-proprietary technology, though.

All in all, it seems to be a decent contender to the FS. It is amazing what 6 months difference can do for technical specs (DroboFS: mid 2010, DS1511+: dec 2010). If only DRI would release that kind of hardware with the BeyondRAID tech (for the same price), it would be awesome.

I took a look at the dropbear readme file and it looks like the developer addressed this issue. Since the DroboApps are 3rd party tools, you may want to post your comments regarding this DroboApps under “Drobo Developer Community”. Thank you.

It is nice that dropbear put a patch in to correct DRI’s poor programming.

I will keep commenting and asking questions HERE about when will DRI correct the problem of their application overwritting the password file everytime the Drobo FS reboots or when modifying users in the Drobo Dashboard.


NEEDED_USERS=“root nobody avahi”



if [ $ret -ne 0 ]; then
echo ERROR: Password change failed. Not doing anything.
exit 1



Root Password has changed in the /etc/passwd, now copy it into /var

for user in $NEEDED_USERS
while read line
/bin/echo $line | /bin/grep ${sub_match}* > /dev/null
if [ $? -eq 0 ]; then
if [ $found == “false” ]; then
echo ERROR: No user $user found in $PASSWD_FILE
echo This user is required. Not Copying to $ALTERNATE_BASE_PASSWD_FILE
exit 1
/bin/echo $copy_line >> $BACKUP_ALTERNATE_PASSWD_FILE


Now add any other lines already in /var/.passwd back into /var/…passwd

while read line
for user in $NEEDED_USERS
/bin/echo $line | /bin/grep ${sub_match}* > /dev/null
if [ $? -eq 0 ]; then

if [ $found == "false" ]; then
  if [ ! -z $line ]; then
    /bin/echo $line >> $BACKUP_ALTERNATE_PASSWD_FILE




echo Root password will be retained from now on
exit $?

Theres the code for the script they use to to the password change.

[quote=“ricardo, post:9, topic:2266”]
My understanding is that if you just try to use the ‘passwd’ command on the shell, it won’t (permanently) change the password for you. You have to use the ‘root_passwd’ script in the dropbear folder.[/quote]

And that is the fundamental problem. “passwd” is exactly how you change passwords on a Linux system. There are standard ways of managing and using users and passwords, and any software we port that needs multiple users (anything with security, really) is going to expect it to work that way.

Everything on this page should work - whereas to my knowledge none of it does - at least, not in any useful persistent fashion:

As a result, we can’t easily get SSH to work properly for multiple users, and we have persistent security holes that are band-aided with “root_passwd” scripts. DRI nukes systems files instead of using standard API’s. Fine, it’s not a bug then, because that would indicate they intended it to work one way, but an error makes it work another way.

This was just fundamentally designed wrong - it’s incompetence.[hr]

And you are completely missing the point, and this ignorance is exactly what is pissing off your users. What is in the readme is a bandaid over DRI’s incompetent programming, and only addresses a single limited use case.

Multiple user support and security on the DroboFS is fundamentally broken. And you, kbradley, are doing DRI no service by passing this off as acceptable.[hr]

Wow. That is one of the nastiest kludges I’ve ever seen.

And it’s brought to me courtesy of my $700 premium NAS device. Given the expandability of the DroboFS though, I’m likely stuck with this for a long, long time - I’m not made of money, so I can’t simply dump my investment and buy a Synology.

It seems Drobo makes a pretty case, some interesting BeyondRAID tech (which based on performance numbers posted elsewhere, is likely responsible for the abysmal performance compared to competitors), but can’t do basic things like user administration or buy quality fans and power supplies.

While I agree Drobo makes some strange decisions, the root password thing seems to be a strange thing to complain about. The only way to change your root password would be if you installed a use at your own risk 3rd party app; they very same 3rd party app that comes with the script to change the password. Making it so that the default password resets seems like its working as intended to me, since they obviously went out of their way to set it up that way, most likely so people wouldn’t end up locked out of their own drobos.

Unless I’m completely missing something, I don’t really see why its a big deal its like that either, if the only time that password comes into account is when you install 3rd party apps, and the 3rd party app even comes with a way to change it, then who cares? Its clearly a feature implemented and working exactly as it is intended. The drobo isn’t made to be a personal linux computer. You can’t expect it to work they same way it would if you just did a fresh install of linux.

TBH, the drobo is a expensive machine to just buy and hope that it works the way you want it to when you get it. I don’t see any reason to assume that when you received it, that it would respond and work how you wanted it to with SSH and multi users. Its not even a supported feature to be accessed that way!

It seems like such a silly thing to complain about so angrily.

Indeed. A close inspection of the service.sh file that ships with the dropbear app indicates that unless the dropbear is installed, the SSH service is not even run. Service not running == not a security hole.

I have seen much worse, security-wise. The good people at nas-central ship Freelink with the same ssh host keys for every install. The dropbear droboapp at least has the decency to generate a fresh new set of keys.


Careful there, man. You are making one very strong assumption, that a DroboFS is supposed to be a ‘standard’ Linux system. Nothing could be further from the truth. My cell phone runs Android, which is a Linux kernel with a Google UI on top of it. Can I use ‘passwd’ to change passwords or create new user accounts there? No, I can’t. My TV is a Samsung LED Series 6. That TV uses Linux for its embedded apps. Can I use ‘passwd’ or ‘adduser’ on it? Nope again.

The cool thing about the Drobo is that anyone could release a new ‘droboapp’ that would contain only especially compiled versions of all those standard default utilities to work with the Drobo’s weird way of handling user accounts and passwords. Heck, even a bunch of simple scripts would do it (I’m thinking diff+patch, but have to test first).

In other words, besides the fact that we need someone to release a proper version of these command-line utilities, I don’t really see where the security issue is (given that you already can permanently change the root password and all the other default accounts are not allowed to login).

If by wrong you mean not supporting your use-case. That is a fair assessment from your side, but do not mistake this for incompetence. DRI is selling a consumer product, and is not trying to cater for people looking for a stand-alone Linux server. The fact that they allows us easy access to its Linux entrails should not be mistaken as an endorsement or even a guarantee of compliance to Linux standards. In other words, they allowed us in, but they are not throwing a party especially for us.

You are right that for what it costs, the FS should have offered more. As of today things are very much a hacker’s club only. Yet, it is still within DRI’s realm to provide us with a simple firmware upgrade to make it easy for everyone. I’m not holding my breath though, and went down the harder path of doing the stuff myself.

Again, the terminology is a bit heavy. It is not fundamentally broken. If you put the right info on all the files that the FS requires, then multi-user support works just perfectly fine. I mean, even out-of-the-box I was able to configure NFS to work with the ‘nobody’ account just fine. That means that the fundamental muti-user support works, as long as you can make the user information persistant.

What does not work are the user-level command-line tools. There I agree a 100% with you. But as I said previously, that can be easily fixed with a new set of binaries/scripts to wrap around the default utilities and ‘fix’ them.

As kludges go, it could be worse. That script is actually pretty clean, although it could probably be made much shorter using diff and patch. Now that you mention it, I think I might give it a try to create that droboapp with the ‘fixed’ versions of the commands. Let me give it a spin and see what I get out of it.

[quote=“ricardo, post:18, topic:2266”]
You are making one very strong assumption, that a DroboFS is supposed to be a ‘standard’ Linux system. Nothing could be further from the truth. My cell phone runs Android, which is a Linux kernel with a Google UI on top of it. Can I use ‘passwd’ to change passwords or create new user accounts there? No, I can’t. My TV is a Samsung LED Series 6. That TV uses Linux for its embedded apps. Can I use ‘passwd’ or ‘adduser’ on it? Nope again.[/quote]

Are you expected (“you” being the community) to port Linux packages to your TV or even Android? Typically not. In both cases, you are provided with a higher level API to work with. For DroboFS, we are porting Linux packages, and they expect the Linux environment to be sane.

Or… perhaps DRI could stop nuking a system file they have no business overwriting. You realize that all of your justifications are coming back to defending one thing: nasd overwrites passwd. There is no reason to do this. This has nothing to do with “oh, it’s not a typical Linux system”. It is a typical ARM-based Linux system in almost every way, except that this breaks the user and password system. And there is absolutely no reason to do so!

Doing this in the first place is incompetent. Not fixing it in six months is kind of sickening and shows a deep lack of respect for paying customers. Strong words sometimes fit the situation.

Next time you reply to this, please show me other examples of how this diverges so strongly from a standard Linux system that we shouldn’t treat it as such (and therefore, really should stop porting standard Linux packages, if it’s so different). Either that or come up with a rational engineering reason to overwrite a core system file like this when there are standard methods of using it, and doing so breaks many applications and use cases that depend on the functionality.

[quote=“diamondsw, post:19, topic:2266”]

I…it’s done by CHOICE. There is no “fix”. Obviously if they went out of their way to do things this way they are not going to turn around and call it a bug and release a fix for it. You may not agree with the choice to do so, but it is done this way by design. Maybe they did it because they wanted it so that if someone every DID try to change the root password, they would not be able to for whatever reason (so they could service them if they got returned, so that they don’t get a I forgot my password call, whatever.)

Your argument is that there is a bug with the drobo that causes it to not remember passwords after a restart, but that isn’t the case. In fact, its a password you shouldn’t even be able to get to, or mess with, under normal operating circumstances of the drobo. After installing 3rd party software, you CAN access this, but that same software has a work around.

Why is this such a big deal? I mean, any app that is designed for the Drobo that could possibly be effected by this will easily be able to work with the way Drobo handles the password…since the app would be designed for the Drobo.

This will NEVER be listed as a bug to be fixed. Maybe one day they might change how the Drobo behaves in regard to this aspect, but it would not be a “bug fix” as much as a “feature change”.

Is it a stupid, unnecessary, worthless, incompetent way to handle things? Maybe. But until a offical work from DRI about WHY they decided to do things this way we will never know. If they went out of their way to do it this was I’m sure they had a good reason at the time. Is that reason valid and still hold true? We’ll never know until we know what the reason is in the first place.