My Drobo is broken after firmware 1.2

I upgraded my firmware to 1.2 to support TimeMachine in Lion. TimeMachine works but…

  1. TimeMachine backup now is slower than mollases.
  2. I can log in as Admin but I get kicked after a few seconds, and nothing changes when I do login anyway.
  3. It seems like the drobo just stops working at times too.

Please give me a link to the older firmware, this 1.2 messed up everything and I dont care enough about TimeMachine to endure this pain.

I cannot register my drobo on the website either as it does not give me that option.

The problem here is only partially the fault of DRI. Lion requires a new authentication mechanism that is really CPU intensive. In fact, there are reports from all NAS manufacturers that all NAS boxes based on ARM (like the Drobo) will have a hard time with that new authentication mechanism.

So yeah… we can blame DRI for putting a weak CPU in the Drobos, but mostly Apple is at fault here. That does not excuse DRI from not giving us links to the older firmware.

Thinking about it now, I wonder if I can compile a better version of netatalk for the FS… that would be pretty cool. :slight_smile:

Interesting - here I thought the incredibly slow speed was just, well, DroboFS as usual. The last thing we need is for it to be even slower than it already was, especially on AFP. I may finally give up and switch to Samba, as it really is almost useless now.

I’ve been using NFS since almost day one. Though completely insecure in a hostile network, NFS is great for Unix-based, trusted networks.

Ah, but I’m guessing NFS has little to no support for Mac-specific metadata that aren’t a part of ext3 (things like file labels, spotlight comments, and all that). For AFP, all of that is handled by Netatalkd, which is why we tend to be stuck with it, for better or worse.

As much as I’ve come to rely on said metadata, I’m starting to think I’m just going to have to make do without it, as the performance is just abysmal. I’ve been running an rsync on a 300GB folder (with almost zero changes, mind you) all day long, and I only think it’s about half done. This would have taken several hours previously, but would have been done by now…[hr]
In what world does this performance data make sense?

Mem: 186392K used, 2636K free, 0K shrd, 23096K buff, 106192K cached CPU: 1.0% usr 3.8% sys 0.0% nic 0.0% idle 95.0% io 0.0% irq 0.2% sirq Load average: 2.01 2.02 1.91 2/61 10155

How can I have consistently 2-5% CPU usage (95% idle), yet a load average of over 2.0?

I did a quick test: mounted one of my shares using NFS, then added a file label (i.e. marked it with the red color). Unmounted and remounted, and the file label was still there. My guess is that Macs save the metadata using some hidden files. My shares are littered by .AppleDB, .AppleDesktop, .AppleDouble, and .TemporaryItems folders. I haven’t looked too deeply into it, but I’m pretty sure the metadata is stored in there somewhere.

A few caveats though: I’m afraid that netatalk stores the metadata in a different way than Mac+NFS. Therefore, just accessing your shares over NFS may in fact not present the current Mac metadata. You’ll probably have to copy all the files from the AFP share to an NFS share using a Mac.

Here is one of the performance problems with the new netatalk (2.2):

Well, if the netatalk daemon is really hitting the filesystem all the time with ‘du’ (like indicated in the bug report, the load will be huge because all the processes are stuck waiting for I/O, but the CPU is basically doing nothing. In other words, that huge load number is a reflection of the heavy I/O that the new netatalk introduced.

Anyway, I think there is a workaround for this whole debacle. I posted it on a new thread since there are so many people with the same problem.

I am back on 1.1.1 firmware and life could not be better!!!

Wow I’d love to go back to the earlier one also, but frankly not sure it’d work well with Lion or may introduce currently unseen problems down the road… I mean didn’t DRI say the 1.2 was needed for Lion compatibility? I’d love to get an official response on this as well, would be glad to switch back. Meanwhile please keep us posted how it works longer-term on your system as well. thx KV

Can you share the location for the 1.1.1 firmware? I’d like to attempt this as well.



My Drobo is also broken after 1.2, but I’m running OS X 10.6. It sounds like everyone else is having trouble only in Lion?

After upgrading, I can no longer access the Drobo via AFP at all. SMB access still works. Any attempt to access via AFP not only causes a beachball, but it freezes the Finder so hard core that I have to hold down the power button to shut down the Mac.

I followed the directions to install SSH and ran top. There doesn’t seem to be high CPU use. I tried browsing the logs but didn’t know exactly what to look for.


yeah, I am seeing this issue as well. I am on 10.6.8, and my computer totally hangs anytime the drobo is attached. I am a bit concerned with downgrading the firmware, I have heard that it causes data loss. Did any of you experience that when downgrading?

How did you do that? Just downgrade over 1.2.0? I thought that was risky…


I downgraded the same way I upgraded. by holding option or command and then selecting the file. I did not have any problems with the downgrade and did not lose any data but your milegae may vary, as a good practice, back up before you do this.

My experience was similar. I downgraded using the same “manual” update proceedure.

Downgraded here as well, seems to be working fine