I recently exhumed an Iomega 500 GB Home Network Hard Drive (model MDHD-500-N) from the Big Box o’ Drives, with the intent of dumping video files from the Sony HDR-AS30 helmet camera thereupon.
Remember Iomega of ZIP Drive fame? Seems EMC Borged ’em a while back, collided with Lenovo, discarded all the old hardware support, and that’s the end of that story.
Exhuming the setup password from my backup stash wasn’t worth the effort, so I experimentally determined that holding the Reset switch closed while turning the drive on blows away the existing configuration. It woke up, asked for an IP address, got 192.168.1.52 from the DHCP server (you can find that by checking the router’s tables), and popped up the administration console at 192.168.1.52:80 as you’d expect.
The userid will always be admin, but you can change the password from admin to whatever you like; you may safely assume I have done somewhat better than what you see below.
Twiddling the configuration through the IOmega web-based console:
- Device name: IOMEGA-500MB (for lack of anything more creative)
- Group name: WHATSMYNET
- Password: not-admin
- Drag the date/time into the current millennium
- Time Zone: GMT-5:00
- Time Server: 0.us.pool.ntp.org
- Static IP: 192.168.1.10 (suitable for my network)
- Gateway & DNS as appropriate
- Windows File Sharing enabled for the PUBLIC directory
- FTP turned off
- Sleep time: 10 minutes
Changing either the IP address or the password requires logging in again, of course.
I reformatted the drive, just to be sure.
Then, after a bit of Googling to remember how all this works…
A line in /etc/hosts (left over from the last time I did this) gives the new static IP address:
192.168.1.10 nasty
Install the cifs-utils package to enable mounting the drive.
Create a mount point:
sudo mkdir /mnt/video
Create a file (/root/.nas-id) holding the super-secret credentials used to gain access to the drive:
domain=WHATSMYNET username=ed password=not-admin
Then restrict the file to the eyes of the root user:
sudo chmod 700 /root/.nas-id
It’s not clear that the username or domain really make any difference in this situation, but there they are.
Define where and how to mount the network drive with a new line at the bottom of /etc/fstab, which refers to the aforementioned super-secret credentials file:
//nasty/PUBLIC /mnt/video cifs noauto,uid=ed,credentials=/root/.nas-id 0 0
Mounting it with my userid gives the shared directories & files proper permissions for me (and nobody else, not that anybody else around here cares).
So the manual mounting process looks like this:
sudo mount /mnt/video
Adding the user mount option would eliminate the sudo, but manual mounting won’t be necessary after a normal boot when the automagic startup script does the deed.
The drive must have the noauto attribute to prevent the upstart Pachinko machine from trying to mount the network drives before the network comes up. Actually mounting the drive at the proper time requires an additional line in /etc/init/local.conf:
description "Stuff that should be in /etc/rc.local" author "Ed Nisley - KE4ZNU" start on (local-filesystems and net-device-up IFACE=em1) stop on shutdown emits nfs-mounted script logger Starting local init... logger Mounting NFS (and CIFS) filesystems mount /mnt/bulkdata mount /mnt/userfiles mount /mnt/diskimages mount /mnt/music mount /mnt/video initctl emit nfs-mounted logger Ending local init end script
The reason the drive wound up in the Big Box o’ Hard Drives was its lethargic transfer speed; copying a 4 GB video file from either the MicroSDXC card (via an SD adapter) or the previous 750 GB USB-attached hard drive to the IOmega NAS trundles along at a little over 6 MB/s. The camera stores 25 Mb/s = 3 MB/s of data in 1080p @ 60 fps, so figure 1/2 hour of copying per hour of riding. The USB drive can write data from the aforementioned MicroSDXC card at 18 MB/s, so the card and USB interface aren’t the limiting factors.
I’m not (generally) in a big hurry while copying files from the camera’s SD card, because that’s now automated:
#!/bin/sh thisdate=$(date --rfc-3339=date) echo Date is [$thisdate] # IOmega NASalready mounted as /mnt/video in fstab mkdir /mnt/video/$thisdate sudo mount -o uid=ed /dev/sdb1 /mnt/part rsync -ahu --progress /mnt/part/MP_ROOT/100ANV01/ /mnt/video/$thisdate if [ $? -eq 0 ] ; then rm /mnt/part/MP_ROOT/100ANV01/* sudo umount /mnt/part fi
I’ve been discarding the oldest month of videos as the USB hard drive fills up, which will happen a bit more often than before: the drive’s 466 GB can hold barely 35 hours of ride video.
Comments
5 responses to “Iomega 500 GB NAS Drive for Helmet Camera Storage”
Now, make a ring buffer and add an accelerometer so it stores the last hour of ride time automatically, and stops filming a minute after a big crash, so you have non-overwriting auto-documenting.
The camera runs Linux, so it should be eminently hackable, except gaining access requires more black-hat-fu than I can muster.
A
threeone-hour ring buffer would fit on a cheap 16 GB card, leaving me nothing to do but swap batteries every hour. It just ain’t happening…[Edit: We generally ride about an hour. Three hours would eat up too much of the day. Call it a finger fumble.]
hackaday had an article yesterday on someone managing to get root on his camera and convert it to an all-encrypted-all-the-time machine, which I rather like.
But the downside, of bricking the camera attempting to escalate privileges, is a bit daunting. Unless, of course, you just bought a replacement camera off ebay for $30, as I did…
The only reason I know the HDR-AS30V runs Linux comes from the GPL doc in one of the camera’s own subdirectories. Perhaps knowing that it’s running BusyBox would enable an exploit, but, being Sony, they’ve locked everything down: there is no doc on any of the interfaces, at least that I can find. [sigh]
[…] That requires a corresponding credentials file with all the secret info: […]