Iomega Storcenter ix2 SSH access! (for firmware 2+ ; this works for the ix2, ix4, etc.) First – big ups to Christopher Kusek over at pkguild.com for getting this on the web. I’ve already had people comment asking how to do it – so I’ll cover it again here.

Login to your Storcenter with the admin user.
In your browser replace the /home.html?t=1 file at the end of the IP address with /support.html
You will now see the support.html page. There is an icon called Support Access.
Select this link and click the SSH access check box.
Now get on your *nix box or open Putty SSH. Type in your NAS IP address (mine happens to be 10.0.1.5).
Login as root, and the SSH password for your box is: soho[youradminpassword]
That’s “soho” with your current admin password tacked onto the end without brackets.
Thanks again to Christopher Kusek!

We have lift-off. Now what can we do with it? Well, at this point, that depends on how creative you are. So I typed “busybox” at the prompt and a list of currently defined functions came up. If you are handy in Linux you’re probably going to go further and faster then I did. If you have any suggestions after you read what could be a tragic Linux hack – hit up the comments.

How email notification works, why it broke, and how you might fix it.
I was less then excited when I discovered “sendmail” missing from the list of BusyBox functions. How in the hell does this thing send email? I started poking around and the “find -name” command is helpful. I logged into the html settings page on the machine and hit apply to send a test email. At the same time I had “top” running in the shell.

2466 postfix 3744 S smtpd -n smtp -t inet -u
2467 postfix 3492 S proxymap -t unix -u

Okay – smtpd sounded promising. I looked around and found that the Storcenter uses a stripped down version of postfix smtp to send email. Interesting side note: the config files are all there but commented out. As a side project, this device is pretty much ready to be an email server. Postfix uses /usr/local/postfix/main.cf to configure outgoing smtp. The storcenter points to mail.authsmtp.com on the default port smtp 25. It sends the outgoing mail directly to authsmtp.com with a password in the config file.

Authsmtp has a dandy little tester exe for Windows – AuthChk.exe found here http://www.authsmtp.com/support/diag.html This shows me that my Storcenter was not the issue, but it was my ISP (Verizon) blocking port 25 outgoing. This is to be expected, and Iomega should realize that a specified port number in their next release would be a good idea.

How can I fix outgoing email right now? For I AM root.
I first discovered that code in the javascript of the Storcenter’s web interface is what’s dropping any “user@host.com” because of the @ sign. This code is buried in the read only flash and it’s not clear to me how you could change it without breaking open the flash. Probably built with buildroot. I then looked at the port issue and figured that if I could get the NAS to send email out on a different port that mail.authsmtp.com could receive, (25, 26, 2525) I’d be in business. In the postfix main.cf file on this machine it says:

# In the case of SMTP, specify a domain, host, host:port, [host]:port,
# [address] or [address]:port; the form [host] turns off MX lookups.
#
relayhost = [mail.authsmtp.com]

So all we have to do is change this to read:

relayhost = [mail.authsmtp.com]:26

If only it survived a reboot… The main.cf file is located in /usr/local/postfix and symlinked to /tmp – this file gets created and written by the system every time it starts up. I’m pretty sure /sbin/executord -c /etc/sohoConfig.xml is doing it. If you look in sohoConfig.xml you see the mail.authsmtp.com specified. All of this is on the read only flash portion of the unit. I looked into BusyBox some more and found that /etc/init.d is doing the startup work. Long story short, rcS runs all the S?? numbered files one at a time in order. An example: “S20urandom, S39interfaces, S40bond-init, etc, etc…” mounts the drives, starts samba, makes toast, starts interfaces, etc. All I had to do was copy over the main.cf file with an edited one and restart the postfix email service.

What I came up with is a file in /etc/init.d called S73mailport (the 73 is a ham reference, and as long as it’s higher then 60, it runs this last)
Don’t forget to chmod 755 this file to make it executable.

#!/bin/sh
sleep 15
cp /etc/mailport/main.cf /tmp/main.cf
/mnt/apps/usr/sbin/postfix -c /usr/local/postfix reload

As you can see there is a modified main.cf file that I stored in /etc/mailport. I wait for executord to finish writing the config (sleep 6 is too soon) and I copy over it. I then restart the postfix services with the whole command postfix -c /usr/local/postfix reload. If you just type postfix reload it won’t find the config. Now my Iomega Storcenter sends me email on port 26! It survives a reboot, but I’ll admit it’s probably not the sexiest way to do this. Another caveat is that upon a hard shutdown (which I’m not going to test as I have active data on this NAS) I’m willing to bet that it executord will signal the Storcenter to send out an email as soon as it starts up. This will most likely never be sent as it will attempt to go out on the default port 25, before my S73mailport script changes it after waiting 15 seconds. So I won’t get the first email, but I’ll get the “Data Protection Reconstruction Complete: The storage device has completed data protection reconstruction,” once that’s finished. This will clue me into the fact that there is a serious problem on my NAS that needs to be looked at.

Other observations:
* The torrent downloader seems to be written into appweb and uses 60 – 70% CPU when running. It lags the interface and shell hard. So hard that I thought I broke it poking around. This is probably fine when I want to setup a download while I’m in Tahiti, but no good if I’m actively looking at pictures stored on the device. Is there a tiny linux torrent program that can run on this device in the shell? I’m sure.
* The read only file system is kind of BS. The flash and Iomega stuff is stored here, but the device boots off the physical hard drives… So config changes are overwritten, but if a drive were to die – you’re SOL with the interface. Time for the SATA cables and the Linux box to come out.
* Now that I know that I can, I have access to a little computer that can move files around, run little scripts, and possibly provide other network functions like TFTP PXE boot for some old thin clients I have hanging around.

Got ideas? Got a better implementation? Let me know!
– Kris