Technology / Hardware / 

06 Feb 2023

SSH on the Dumpster Drobo

Sometimes you just need to walk away from a project for a while, and come back to it with a renewed sense of annoyance: “why doesn’t this stupid thing work better?” and “why am I even paying for the electricity to run this piece of junk?”

So it was with me and the Dumpster Drobo (a Drobo b800fs, featured several times previously) this past weekend. I think it might have finally heard the threats I’d been making about finding a dumpster to put it back into, because after logging into the “Drobo Dashboard” management application, I noticed something I’d never paid attention to before:

Listed under “Shares” for my Drobo was a share called ‘DroboApps’!

I’m not sure why I never saw this before, or the option under “Drobo Settings” / “Admin Settings” that apparently makes it visible. I choose to believe that the machine had simply not yet been convinced to give up all its secrets. I could also just have missed it.

Anyway, once I mounted that share, I did some searching online; although there wasn’t much info around about ‘DroboApps’ for the b800fs specifically, there was for the closely-related ‘DroboFS’ on DroboPorts.com, which is a great resource if you find yourself with one of these boxes.

(Apparently, they make pretty good newsreader / NZB downloader boxes. Who knew?)

With the SSH “app”—a self-contained TGZ of Dropbear, I believe—installed, and after a quick reboot, I ran a quick port scan with nmap, and behold:

Nmap scan report for drobo.lan
Host is up (0.0025s latency).
Not shown: 996 closed ports
PORT     STATE SERVICE
22/tcp   open  ssh
548/tcp  open  afp
5000/tcp open  upnp
5001/tcp open  commplex-link
MAC Address: 00:1A:XX:XX:XX:XX (Data Robotics, Incorporated)

An open ssh service on port 22!

I’m not entirely sure what the commplex-link business is, up on port 5001 (some Googling only finds other bewildered people asking the same question), but that’s a problem for a different day. Time to log into this thing!

First, I tried logging in as admin, with the same password I use to access Drobo Desktop: no dice. So then I tried that favorite default: admin with password “admin”. No again. Okay, maybe root instead? With no password? No, that’d be too easy. With the Drobo Desktop password? No. Maybe root with password… “root”? That’s just stupid enough to work.

And it did!

It turns out that with a freshly-installed SSH / Dropbear instance, the default account is just root/root. (Guess I’ll have to fix that.)

But finally, after having this thing sitting in my closet since the beginning of The Great Pandemic of 2020, I have a root prompt. Time to see what we’re dealing with inside this mystery box:

# uname -a
Linux Drobo 2.6.22.18 #1 Thu Nov 19 15:41:43 PST 2015 armv5tejl GNU/Linux

Wow, Linux 2.6. That’s rather retro, by 2023 standards. (And if we’re being honest, it was pretty long in the tooth back in late 2015 when this thing was apparently compiled, only a few short months before the 2.6 kernel in general was EOLed, and when most of the world was well into the 4.x series. Ouch.)

But armv5tejl lets us know something about the Drobo’s architecture: it’s based on ARM v5, specifically the v5 “TEJ” instruction set subtype. It was formerly a supported Debian platform, but was dropped in Debian 10. Still, even Debian 9 (aka “Stretch”) would get it up to kernel 4.9. So that’s something to keep in mind…

# ssh -V
OpenSSH_6.8p1, OpenSSL 1.0.2a 19 Mar 2015

Well, that’s not great. Could be worse, I suppose. Let’s see what else this thing is running:

# ps w
PID USER       VSZ STAT COMMAND
  1 root      3032 S    init
[ ...boring stuff skipped... ]
183 root         0 SW<  [dri_dnas_thread]
186 root         0 SW<  [mtdblockd]
187 root         0 SW<  [nftld]
198 root         0 SWN  [jffs2_gcd_mtd1]
206 root         0 SWN  [jffs2_gcd_mtd2]
224 root      1584 S    /sbin/netplugd -P 
228 root      3036 S    /bin/sh /usr/bin/nasdLogRotate 
230 root     34228 S    /usr/bin/nasd-fugi 
231 root      3036 S    -/bin/sh 
295 root         0 SW<  [dri_shared_res_]
296 root         0 SW<  [dri_scsi_resp_2]
297 root         0 SW<  [dri_scsi_req_3]
299 root         0 SW<  [scsi_eh_0]
319 root      3032 S    udhcpc -i eth1 -s /etc/udhcpc.sh -b 
336 root         0 SW<  [kjournald]
341 root         0 SW<  [kjournald]
393 root      5544 S    /sbin/nmbd -s /mnt/DroboFS/System/samba/conf/smb.conf 
395 root     10060 S    /sbin/smbd -s /mnt/DroboFS/System/samba/conf/smb.conf 
396 root     10060 S    /sbin/smbd -s /mnt/DroboFS/System/samba/conf/smb.conf
414 root      6264 S    /sbin/afpd -F /mnt/DroboFS/System/netatalk/conf/afpd.conf 
  -P /mnt/DroboFS/System/netatalk/security/afpd.pi

Well, that’s a pretty good view under the hood: pretty standard. smbd for Windows SAMBA file sharing, afpd for traditional Mac sharing, udhcpc as a DHCP daemon; probably the same stuff you’d install if you were setting up a file sharing server on your own hardware. And it lets us know where the config files are for the various services, which is convenient if we want to tweak something (or inadvertently break something).

But what is nftld? mtdblockd? nasd-fugi? New ones to me.

From what I can tell, mtdblockd is a Linux driver that provides a clean block-device API to a number of Flash-based storage devices – presumably rather simple ones that don’t contain logic themselves to present as some other kind of device, like SATA or an SD card. So there must be some of that in there, perhaps for the OS itself.

Unfortunately, nftld is difficult to search for due to the many “NFT” items polluting the Google search results. The only mentions I could find of it, are in conjuncton with ARM-based appliances like the Drobo, so it might be worth looking into as part of the Drobo ‘secret sauce’. Same with nasd-fugi.

But before we go down that road, a tour around the filesystem:

# cd / && ls
bin      dev      etc      lib      linuxrc  mnt      proc     root     sbin
sys      tmp      usr      var
# ls mnt/
DroboFS   DroboFS1  DroboNAS
# ls mnt/Drobo*
mnt/DroboFS:
Shares      System      SystemLogs  home        swapfile
mnt/DroboFS1:
Shares      System      SystemLogs  lost+found
mnt/DroboNAS:
Shares      System      SystemLogs  home        swapfile
# ls -l /mnt/DroboNAS
lrwxrwxrwx    1  root root   7   Nov 19 2015  /mnt/DroboNAS -> DroboFS

That’s a bit interesting. There are two filesystems under /mnt, DroboFS and DroboFS1, and then a symlink called DroboNAS pointing to DroboFS. That might making using rsync to move data to this device a bit more challenging. Wonder what the deal is there…

I’m going to end this here, just in the interest of actually getting what I’ve found posted, and hopefully follow-up with some more useful information as I get a chance to spend more time digging into the device and what can be done with it.