Lion and Drobo TimeMachine: a workaround

I’ve noticed that quite a lot of people are having serious performance issues with the new Mac OS X Lion and the 1.2 FS firmware.

TL;DR: Try the steps presented in this page: http://www.alexanderwilde.com/2011/04/os-x-lion-connection-error-with-afp-and-workaround/

My investigation so far indicates that the problem is three fold: 1) The DroboFS has a quite slow CPU, 2) Apple changed the authentication mechanism used in the TimeMachine which now uses a much more CPU-intensive algorithm, and 3) The latest version of the software used by DRI to provide TimeMachine functionality (netatalk) has some serious performance bugs.

As you can see, this is the worst kind of bug there is, since several parties are at fault:

  1. If the Drobo CPU wasn’t so slow, this wouldn’t be so much of a problem
  2. Apple thinks that the previous authentication mechanism is not secure enough, so they disabled it by default
  3. The guys at netatalk went to the dark side, and decided to close the source of netatalk for this release (quite the scummy move, IMHO, but that is a different discussion) thus making it impossible for the community to try to fix the bugs

My advice to Lion owners that still want to have TimeMachine functionality on their Drobo is to go back to the previous FS firmware (thus getting rid of the new, buggy, netatalk) and then enable the old authentication mechanism on their Lion machines as indicated on the link above.

On a side note: I find it funny that the previous authentication mechanism is insecure enough to warrant a sudden change in Lion, but not insecure enough to warrant a patch to the previous releases of the OS… stay classy Apple.

Problem with this is, you can access AFP shares but Time Machine still needs the new firmware to work.

You are absolutely right. I overestimated the reach of this workaround.

Here’s a good rundown of the problem: http://trick77.com/2011/07/15/about-os-x-lion-nas-time-machine-compatibility-netatalk-gpl-violations/

Apparently, the workaround only allows you to access AFP shares using the old firmware (i.e. netatalk 2.1). The new firmware (netatalk 2.2) also supports extensions that were made to the TimeMachine protocol that are not present in netatalk 2.1.

It is possible to compile netatalk 2.1 with support for the new authentication (see here) so that the workaround wouldn’t be necessary, but it still wouldn’t work with the new TimeMachine clients.

Drobo is a Netafp customer by the way. http://www.netafp.com/customers/ So they should have access to the latest 2.2 version.[hr]
At first I also had the impression that it must be the slow Drobo CPU that is at fault, but I’ve one of those slow Lion Time Machine backups running right now and the CPU isn’t using that many cycles. So maybe there are some commands missing in the current protocol version or it is something stemming from Lion itself.

my time machine to droboFS also broke with lion upgrade.
after firmware upgrade, at first, it wouldn’t even work.
second reboot and it detected the share on afp, but TM got stuck on “preparing backup”.
rinse, reboot, it got stuck at “indexing backup”.
another reboot later its backing up, but its been trying to transfer 9GB, and i let it run for 20+ hours and now its still stuck at 445MB.
max transfer speed is 6KBps!

anyone know if i can move the sparse bundle to a USB disk as a temp workaround?

Like I said, the longer I see this issue the more I have the impression that Lion itself might also be involved in this problem. It’s not only Drobo or NAS customers who are experiencing this problem, there are also Time Capsule users who are in trouble.

See #D1 and #D2 for more information:

thats a very helpful link.
thanks a bunch :slight_smile:

i’ve now stopped using the drobo share for TM.
backing up to USB for now.
will post back if i’ve more info.

I’m doubtful of that - there may be multiple issues at play that appear the same, but I don’t think there’s a common bug here. The performance issues seem very much due to changes in netatalkd, which is used on all of the Linux-based NAS units. The Time Capsule issues you reference look more like standard Time Machine troubleshooting - some of which I’ve found to be caused my problems with Spotlight. And there’s always a lot of Spotlight reindexing after an OS upgrade.

I’d expect Time Capsule users to be fine (I am), but Linux NAS users may be hosed unless netatalkd improves. From the sounds of it, the people running the project have closed the source, are being rather greedy, and prioritizing portable code over workable code.

I’m starting to look at switching to SMB. I’d do NFS, but the security isn’t what I’d like.

Well I wouldn’t call them greedy, making a living with what you do is only fair. And it sounds like NAS vendors are willing to support it.


Which hasn’t been the case before:

Sigh, yet I am the one to pay for something that is completely above my head.

Well, the netatalk situation is kind of murky. Previous versions were released under the GPL, which states that, sure, you can charge but you can’t withhold the source once you start distributing the binaries. Not only that, what about (external) people who contributed patches and new code to netatalk in the past? Are they getting their share of these “licensing” deals?

Here’s an interesting experiment: ask DRI for the source code for the latest firmware. Since everything is GPL’ed, they have to send you everything, including the new netatalk, if that is still GPL. If netatalk is no longer GPL, then get ready to see some swift butt-kicking from the FSF.

It’s always possible that they relicensed the new version as non-GPL - but that is very hard to do, as you have to get every single contributor to agree.

Perhaps it’s not greedy per se - but it’s hard to paint it as a good thing.

I can’t even mount my Drobo FS shares from Lion using smb. It won’t authenticate. Mounting using the new Dashboard works (i.e., AFP) but then it’s so slow as to be useless.

My connections from Lion to my Windows Home Server are fine and fast. Something is strange with the Drobo.


They are violating the license of software they did not originally write. It is essentially the same thing as trying to make a living selling pirated software DVDs.

Well, if we want to be extremely nitpicky about licenses they are not actually stealing anything. Netatalk is licensed under the GPL, and nothing under the GPL forces you to release newer versions. What it does say, however, is that once you start distributing binaries you also have to provide the source.

It is quite obvious that the binaries have been distributed, since a new FS firmware has been released. The question is now is whether or not the source is available. That is why I mentioned asking DRI for the source of the new netatalk. As distributors of the new FS firmware, they are bound by the GPL to provide the source*. Of course, if they can’t/won’t, then they are liable for a GPL infraction. However, if they are able to prove that they were never given a source version of netatalk (i.e. the netatalk guys only gave them the binaries) then the liability goes upstream.

That does not mean that the netatalk guys are standing on a moral high ground, though. My analogy is that of a hostage situation: the netatalk guys saw an opportunity to make a quick buck with the release of a standard-breaking “upgrade” of Mac OS X, and thought “frak the community, let’s cash in on ‘support’ contracts”.

TL;DR: If DRI has actually paid the ‘ransom’ for the latest netatalk through a “support” contract, then they better start asking their money’s worth. They should go demand that the code actually performs as well as they claim on their commercial site.

*) Of course, this only applies if netatalk is still licensed under the GPL. That being said, the odds that netafp (or whoever is maintaining netatalk at the moment) will try to change the license of netatalk now are basically nill, for the reasons diamondsw listed above.


The politics of the situation isn’t going to get us anywhere. Can anyone please tell me what has to be done to go back safely? That is, I want the old Drobo Dashboard (can’t stand the flashy new version), Lion gone and my Drobo FS working faster than a 300 baud modem.Can you in fact safely go back in firmware?


Yes you can go back, I did and its wonderful but TimeMachine will not work if you are running Lion, but that is not a concern to me that much.

You can simulate the exact same behavior of Time Machine using rsync: http://blog.interlinked.org/tutorials/rsync_time_machine.html

You don’t get the fancy GUI, though.

Note that you will need the custom version of rsync that will preserve all Mac OS X metadata, and that rules out any direct daemon-to-daemon syncing (well, unless the remote daemon also has all of the appropriate patches, and a way of storing the data on a foreign filesystem).

Are you sure those patches are still needed? It seems that the bug reports have been closed as fixed, so I assume the latest version or rsync (3.0.8) does not need the patching.

Unfortunately, the official rsync DroboApp is rsync 3.0.7, so it probably does not contain the patches. Time for another DroboApp… :slight_smile:


EDIT: meh, I should have known better than to speculate without further googling: http://samba.2283325.n4.nabble.com/3-0-8-OSX-build-hfs-patch-failing-td3429610.html

Apparently the bugs have been fixed in 3.0.8, but if you want to support HFS+ compression a patch is still needed. But my impression is that the HFS compression patch is only needed on the Mac side.