So I installed the hard disks and booted it up. I created a big RAID 6 volume over all disks and then realized that it wasn't helping a lot because, while there was a menu option to enable NFS support in the first place, there was none whatsoever to export my new file system via NFS. Also, showmount confirmed that it wasn't exported.

Follow the manual

As I couldn't find anything in the online help or the user manual about exporting file systems to NFS, I found Thecus N5200 Debian on the Chaoswiki and tried to follow the procedure outlined there. However, it turned out that my NAS was running a much more recent version of the Thecus supplied Linux distribution and couldn't install any of the mentioned packages. Also, Thecus itself doesn't seem to offer any SSH server.

Do It Yourself, maybe?

So since the whole thing is just an i386 which runs Linux I decided to try and go in to fix things up myself. I installed Debian onto an SD card and tried in kvm whether it boots up fine and configures the system. Then I got myself an adapter from PC Engines to mount the SD card into the Thecus NAS and tried to boot it up.

Well, so much for the theory. The system did something but there was no output on any of the two serial consoles, ever. Not even the firmware of the box write anything anywhere. The system is really hard to interact with. And while, in qemu, I get a serial console, it didn't work at all in the Thecus.

And while the network card was configured and the firmware installed, nothing moved on that front either. According to Running Debian on Thecus n5200 on wpkg, the only way to tell what the NAS is doing seems to be to solder a VGA adapter onto the mainboard and attach a monitor.

Picking up the pieces

So to summarize, so far I wasted more than CHF 1'000.- and 10 TB of space. All I got in return is a brick which sits on the ground and can only share files with Windows boxes. Yes, I know, most systems can mount SMB shares, but that's really not an option.

So I really wonder where this is going. What I'd love is a tiny box with space for 5 hard disks which can at least do 1 Gbit/s and can be integrated easily with my LDAP and Kerberos setup. In my world, this shouldn't be too much to ask.

However, instead of this, vendors seem to throw very expensive closed systems at us which attempt to prevent us to customize them or to really interact with them in any way which the vendor wasn't planning for. I don't see the reason though.

What's the loss for Thecus if I can easily install my own operating system, like I can with my ALIX? They aren't losing any money form this or anything. What's the cost of making everything output to the existing serial port? It's not like this is expensive to implement or anything. And the operating system used in the box suppports it just as well.

So far I'm getting the feeling that I just found a new brick I can use as a door stopper. But I guess I'll try to do some more stuff with it before I loot the hard disks. Perhaps I should buy a regular Mini-ITX PC and use that.

Thinking I had found the cause of my problems, I went on to create my own bootable USB stick — unsuccessfully of course. The /boot partition, which is located at the beginning of the device, always remounted itself read-only when I tried to install the kernel or grub. Sometimes it even showed up as read-write in /proc/mounts, yet it wasn't writable. So I started looking for SElinux context problems — none.

Attempting to set an explicit SElinux context for the /boot partition upon mounting, I unmounted the /boot partition, only to get some terrible notifications in my dmesg:

 Mar 10 11:51:54 methusalix kernel: ext3_abort called.
 Mar 10 11:51:54 methusalix kernel: EXT3-fs error (device sdb1): ext3_put_super: Couldn't clean up the journal

Yet somehow, it was unmounted. I tried to mount the partition again, which yielded:

 Mar 10 11:56:24 methusalix kernel: journal_bmap: journal block not found at offset 12 on sdb1
 Mar 10 11:56:24 methusalix kernel: Aborting journal on device sdb1.
 Mar 10 11:56:25 methusalix kernel: __journal_remove_journal_head: freeing b_committed_data
 Mar 10 11:56:41 methusalix kernel: ext3_abort called.
 Mar 10 11:56:41 methusalix kernel: EXT3-fs error (device sdb1): ext3_journal_start_sb: Detected aborted journal

In the end, the file system was not mounted. Great. So I ran a file system check, which crashed with ”Too many errors in inode …“

So my next idea was to run badblocks, so I tried to umount the root partition of the new system on the stick, and got some more nice kernel messages:

 Mar 10 11:57:01 methusalix kernel: EXT4-fs error (device sdb2): ext4_mb_generate_buddy: EXT4-fs: group 0: 6936 blocks in bitmap, 7095 in gd
 Mar 10 11:57:01 methusalix kernel: JBD: Spotted dirty metadata buffer (dev = sdb2, blocknr = 0). There's a risk of filesystem corruption in case of system crash.
 Mar 10 11:57:01 methusalix kernel: JBD: Spotted dirty metadata buffer (dev = sdb2, blocknr = 0). There's a risk of filesystem corruption in case of system crash.

Mount returned ”umount: /mnt: device is busy.“ although lsof did not reveal any users of the file system. All I could do at this point was to reboot and run badblocks thereafter. After running for approximately 1 ½ hours, it finally displayed:

 3921914
 3921915
 3921916
 3921917
 3921918
 3921919
 done                                
 Pass completed, 798052 bad blocks found.
 tonnerre@methusalix:~% 

I don't think there's any rescue for this USB stick.