Today I experienced one of these problems: My colleague in Berlin had that external hard disk drive. It was connected to a Buffalo TeraStation (that’s a NAS, sort of, with a super small linux). It was used as a backup drive there.

Now the TeraStation was horribly, almost hilariously damaged. It couldn’t be accessed from Windows machines anymore because the smb.conf was completely empty. I could edit it with vi (you don’t have vim on that minilinux) and save, nothing would happen. I could also echo stuff > smb.conf – it would always stay 0 bytes in size. Yes, I was root, I was owner, smb.conf had 777, everything. Whatever, that’s not my point here. Just as advice: NEVER EVER BUY SUCH CRAP!

So, anyway, the data stored on the TeraStation was very important and needed to be accessed. Unfortunately, the TeraStation does not ship with SSH, but I was able to get into it via telnet. A few months earlier, I hacked the crontab (a “little” security hole in that firmware) which let me run a script with root privileges, so I managed to chmod the /etc/sudoers to 777 and – finally – get root access.

However, I wanted to get the data. There is rsync on the TeraStation, but it can’t be used to transfer files over the network, because – as I mentioned before – there’s no SSH. Also, I couldn’t mount the samba shares with mount.cifs on another server, because the samba shares obviously were gone.

Disassembling the TeraStation and connecting its hard drives to another computer wouldn’t make sense because a RAID array is being used. But hey, we have that external hard drive that the TeraStation makes its backups on, right? Right. Now guess what, the TeraStation uses XFS for the external drives. No big deal, I thought. Mounting that external drive on our server failed though with the message “xfs unknown file system”. I yum-installed xfstools and tried xfs_check and xfs_repair, but none helped.

So I decided to read me a little into what XFS is. Wikipedia told me some unimportant stuff about it, and at the bottom of the page (where the fuck else?) there was a note that mentioned that xfs is actually dependant on the architecture (i386, x86_64 etc.) and that I’d have to “clear” the journal when migrating to another architecture. Now this would make sense, since the TeraStation has a PowerPC processor and the server uses two Xeon processors. So again I read man pages for xfs_repair. There was an -L switch mentioned, but it was said to be dangerous and could potentially lead to data loss. And what kind of a sysadmin would I be risking my company’s precious data? It turns out my colleagues in the local branch in Berlin (where both the TeraStation and the server are) do have an old Apple Mac G4 there. Guess what, that’s a PowerPC.

So I told my colleague there to download the System Rescue CD for PPC and boot that Mac with it, so I could hopefully access my XFS-formatted external drive from it. And yes, mounting worked like a charm. After he configured the network interface with dhcpcd eth0, I told my colleague to start the ssh server so I could go on working. He did, and I tried to ssh onto the Mac. After entering username and password (yes, he did passwd root beforehand), I got a “Server refused to allocate pty” error. What, no free terminal for Jay?

Once again, Google found the solution:

On the System Rescue CD for PPC 0.2.0, there’s no devpts fs in fstab, hence it’s not mounted on boot. Accordingly, one cannot ssh onto the system. Doing a quick mount -t devpts -o gid=5,mode=620 none /dev/pts did the trick. Finally, I was able to start scp’ing the data onto the server.

This was only a small excerpt of today’s adventures with the TeraStation – I started working on 8:20, now it’s 21:13, I didn’t have any break, so I worked approx. 13 hours nonstop on that shit.

Never. Again. TeraStation.

Oh, guess what day it is today? Correct. Monday.