Rupert Goodwins' Diary

Wednesday 20/09/2006

I look at the clock. It's 4am. I'm savagely reminded of Microsoft's run in with the Europeans, which has a direct bearing on my lack of sleep.

Let's go back to the end of last week, when Intel sent me an SS4000-E. As this is a four-disk terabyte network attached storage device, this was jolly decent of them, and I immediately hooked it into my home system of three PCs. They run a mixture of Windows and Linux on various multiboot and VMWare ways, and having a proper standalone storage server is a very welcome addition. I've been using a Linux laptop as my media server, so if I can just mount the SS4000-E instead of its media directory, everything should carry on as if nothing had happened — except the 60GB hard disk had grown by 15 times.

In theory, you can do this with a single command in Linux — or a single line in a configuration file. Neither are the simplest of single lines, because they have to contain a lot of information: what the server's called, the name of the area on the server you want to use, the user and password with which to log in to the server, and the sort of network protocol it speaks. It's also fair to say that the way Linux handles storage is a bit alien to a Windows spod, so I wasn't too surprised when my first couple of attempts to hook things together didn't work.

Never mind, I thought, I'll set aside an evening and just get stuck in. Shouldn't take more than 10 minutes to find out what I'm doing wrong. Tonight at 8pm, I set to work.

By 4am, I have learned a great deal. I have learned that the SS4000-E has some curious limitations that don't matter to Windows users but matter quite a lot if you want a mixed network. I have learned that there are ways to get around these limitations, but you need to make your Linux computers use the Microsoft SMB networking protocols. I have learned that there are two network filing systems you can use for this, smbfs and cifs.

I started off with the smbfs, because it's older and much more tested. That worked — for a bit. After half an hour learning how to set it up, I had my terabyte directory sitting on the laptop, but when I tried to copy across my existing media files the share froze after a while. Sometimes it was 10 gigabytes, sometimes 20, but it never made it any further.

It proved — after two hours and a VoIP call to my Linux guru in Sweden — to be an obscure unfixed bug in smbfs. Furthermore, the developer for said code had vanished, so the team looking after the complete package had resorted to saying "Don't use smbfs, it's out of date. Use cifs instead, it does the same job but is being actively developed".

Which was good advice, mostly, were it not for me failing completely to make the darn thing work. The share appeared on the Linux desktop, but was untouchable — "Permission denied" said the computer when I tried to read or write anything on it.

Two hours later, it proved to be an obscure bug in the Linux code on the SS4000-E. This one had been fixed — last month, as it happens — but the version on the NAS box was older than that. There was a helpful note in a support forum: "If this affects you, use smbfs instead. It's older, but does the same job".

Thanks for that. I briefly wept, then fixed the problem through the unoriginal sin of running as root on the Linux box (and if you don't know what that means or why it matters, I envy you).

And Microsoft's role in this? The SMB protocol at the heart of all this is the one it refuses to share in its entirety with the rest of the world, and the one that the Europeans have decided gives the company an unfair competitive advantage. It certainly does: by ensuring that it is far harder to interoperate reliably with Windows boxes, Microsoft is keeping Linux on the defensive — and ruining my sleep.

Go, Europe.