Drobo

Firmware 1.2 killed two shares

After the 1.2 firmware update, one of my shares will not show any files. As in, even “ls -al” on the mount point shows nothing - not even invisible files. Sadly, I got an alert about a corrupted CNID database that “could not be recovered from” - and when I tried to copy it, apparently it didn’t work.

SSH’ing in reveals that all of the files themselves are intact, but these are Mac volumes - without the metadata stored by netatalkd in the CNID database, they’re as good as toast.

That’s probably 1.5TB of data that just went up in smoke.

I suspected that this is an issue with netatalk. A bit of googling gave me this: http://ubuntuforums.org/showpost.php?p=11077808&postcount=7

Does this help at all?

Afraid not - it didn’t even try to switch to a temporary DB - it actually said “recovery not possible” or somesuch (I really wish I had a copy of that error message, as I’m not finding any trace of it via Google).

Deleting all .AppleDB files via SSH and rebooting did the trick it seems. Files list now, and the metadata looks intact - which makes me wonder what the purpose of that database is.

Same issue… updated DroboFS with firmware 1.2 and got the following error message:

Transcription: Message from server “Drobo-FS” Something went wrong with the volume’s CNID DB, using temporary CNID DB failed too!Check server messages for details, can’t recover from this state!

I also requested a tech support ticket and will update this thread if/when I hear back from them.

Meanwhile, can you let me know the exact procedure you did to delete the .AppleDB you mentioned below? FWIW I’m running Mac OS X Lion and have no experience with SSH, so details would be great.

thx KV

Same just updated to 1.2 and nothing on my (one and only) partition “TimeMachine”. Can’t even get Time Machine to use the partition.

This same thing happened to me with one of my shares last night when I updated. However, when I browsed to the share from Windows, the files were all there, which was a relief. I figured if nothing else, I could make a new share and move the files using Windows. I never got around to doing that, though, because today when I tried connecting again from my Mac, it mysteriously started working again.

Hopefully, the same magic will happen to others.

back from Firmware 1.2 to 1.1.2 ?

This isn’t a new problem. This has been a firmware bug since at least the beginning of this year. I’m theorizing that something in the update is precipitating it to happen more frequently on upgrade. Drobo have known about this for a while, and the workaround and fix (I know because I’ve told them), but have yet to fix it or post anything about the workaround.

Here’s how you get your data back and the ability to connect to the share:

  1. Enable SSH access, to do this:

a) Enable Drobo Apps in the Dashboard (checkbox under Settings / Admin)

b) Restart Drobo

c) From here: http://www.drobo.com/droboapps/ download DropBear ssh

d) Under your shares, you’ll have a new folder called “DroboApps”, drag
the .tgz from c) into this share

e) Reboot drobo and wait a while for everything (including ssh) to start up

f) ssh to your drobo with: ssh root@IP_ADDRESS (where IP_ADDRESS is the ip address of your drobo)

  1. Zapping the corrupt database. First make sure no machines are using your drobo.

a) cd Shares

b) ls (look for your TimeMachine partition, lets call this “MyTimeMachine”

c) cd MyTimeMachine (note if you want to be reassured your files are still there, type ls. If you don’t see them, then a corrupt database isn’t your issue.)

d) mv .AppleDB .AppleDB2
mv .AppleDesktop .AppleDesktop2
mv .AppleDouble .AppleDouble2
(you can delete them if you prefer)

e) /sbin/reboot (restarts your drobo)

f) ssh into your drobo again

g) Use “ps” to see if a process is running (/sbin/cnid_dbd), this process indexes your drive. It should NOT be running at this stage.

h) Login to your share in the Finder. You will still see no files, and you may get the pizza wheel after a while, don’t to anything. Eventually this connection will prompt the drobo to reindex.

i) Be real patient and wait. At some point, ps will show cnid_dbd running, and you’ll see that the Share/MyTimeMachine will now populate .AppleDB. After potentially a long time (on mine it took 20mins for 1.46TB Time Machine), you’ll see the finder get populated with your Time Machine files.
At this point, you should now be able to use Time machine again.

  1. Finally, switch of “DroboApps”, unless you don’t care about the security risk.

I’ve only seen this happen on TimeMachine volumes, but if you’re having the same issue of other shares the same procedure should work on those too.

Note you have to login to the share and have it displayed for the .AppleDB to be recreated.

This isn’t a new problem. This has been a firmware bug since at least the beginning of this year. I’m theorizing that something in the update is precipitating it to happen more frequently on upgrade. Drobo have known about this for a while, and the workaround and fix (I know because I’ve told them), but have yet to fix it or post anything about the workaround.

Here’s how you get your data back and the ability to connect to the share:

  1. Enable SSH access, to do this:

a) Enable Drobo Apps in the Dashboard (checkbox under Settings / Admin)

b) Restart Drobo

c) From here: http://www.drobo.com/droboapps/ download DropBear ssh

d) Under your shares, you’ll have a new folder called “DroboApps”, drag
the .tgz from c) into this share

e) Reboot drobo and wait a while for everything (including ssh) to start up

f) ssh to your drobo with: ssh root@IP_ADDRESS (where IP_ADDRESS is the ip address of your drobo)

  1. Zapping the corrupt database. First make sure no machines are using your drobo.

a) cd Shares

b) ls (look for your TimeMachine partition, lets call this “MyTimeMachine”

c) cd MyTimeMachine (note if you want to be reassured your files are still there, type ls. If you don’t see them, then a corrupt database isn’t your issue.)

d) mv .AppleDB .AppleDB2
mv .AppleDesktop .AppleDesktop2
mv .AppleDouble .AppleDouble2
(you can delete them if you prefer)

e) /sbin/reboot (restarts your drobo)

f) ssh into your drobo again

g) Use “ps” to see if a process is running (/sbin/cnid_dbd), this process indexes your drive. It should NOT be running at this stage.

h) Login to your share in the Finder. You will still see no files, and you may get the pizza wheel after a while, don’t to anything. Eventually this connection will prompt the drobo to reindex.

i) Be real patient and wait. At some point, ps will show cnid_dbd running, and you’ll see that the Share/MyTimeMachine will now populate .AppleDB. After potentially a long time (on mine it took 20mins for 1.46TB Time Machine), you’ll see the finder get populated with your Time Machine files.
At this point, you should now be able to use Time machine again.

  1. Finally, switch of “DroboApps”, unless you don’t care about the security risk.

I’ve only seen this happen on TimeMachine volumes, but if you’re having the same issue of other shares the same procedure should work on those too.

Note you have to login to the share and have it displayed for the .AppleDB to be recreated and the list of file to be displayed.

Above fixed the login immediately logout problem on the drobo dashboard and my Time Machine Backup missing.

However the extremely long wait time for the share to mount still occurs and looks like a problem with the latest netatalk.

I’m able to see my files from my old windows machine so I’m going to start down load off the drobo. i think it worked on 1.1 with lion i upgraded because there was a newer firmware. should have left well enough alone

Yes, it is.

http://www.drobo.com/support/updates/firmware/DroboFS_Firmware_1-1-2.dmg