Advertisements

Iomega 500 GB NAS Drive for Helmet Camera Storage

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.

Advertisements

  1. #1 by smellsofbikes on 2014-12-18 - 12:56

    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.

    • #2 by Ed on 2014-12-18 - 15:16

      The camera runs Linux, so it should be eminently hackable, except gaining access requires more black-hat-fu than I can muster.

      A three one-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.]

      • #3 by smellsofbikes on 2014-12-19 - 13:05

        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…

        • #4 by Ed on 2014-12-19 - 13:22

          nice camera for the price that conveniently runs Linux and is kinda open-sourced by Samsung

          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]

  1. RPi: Time-lapse Photos | The Smell of Molten Projects in the Morning