NFS, Windows and Foreign Characters

The house now only has one Windows PC left (running 64-bit Windows 7). Everything else is running Linux -though one netbook still retains dual boot capability, just in case. (In case of what exactly I’m not quite sure, but it always pays to be prepared, I guess). The question now arises, then: how best to get that one Windows PC accessing files from the file server (which is busy running Scientific Linux 6.1)?

The obvious answer is ‘Samba’: a quick fiddle on the file server to install the requisite Samba server packages, a modest amount of editing smb.conf and (usually) all is set and ready to run.

This time, however, I thought I’d be a bit more adventurous. Every other Server, PC, laptop or netbook is running Linux, so why impose the overhead of Samba if it’s not needed for most of the machines on my network? Why not get Linux’s “native” file sharing system (NFS, or Network File System) running instead and get the Windows PC hooking into that?

Well, the NFS bit is indeed incredibly easy to set up. It’s already installed on the server: all I had to do was make sure the firewall allowed traffic through (on ports 111 and 2049), configure an export file and start the relevant service. All done in about 5 minutes, to be honest -which is a lot faster than Samba usually is for me! The export file (/etc/exports) couldn’t be much simpler, either, for it contains just one line:

/safedata 192.168.0.0/24(rw,sync)

The safedata directory is the mount point for my RAID 5 array, so has all the important data on it. I’m just saying here that anyone on my home network is allowed to get read-write access to it (in principle, anyway… normal file permissions still apply, so unless I’ve chmodded everything 777, not everything will be writeable).

The Linux clients are a doddle to configure, too: it’s simply a matter of typing this sort of thing (as root):

mount 192.168.0.100:/safedata /nfsmounts

That just says ‘find the “safedata” export on the file server and mount it at the /nfsmounts mount point’. And, just as I had hoped, I found large files could be copied across to the server from my desktop at a rate of about 48MB/sec. That’s 384 megabits per second, which isn’t bad for my rather humdrum gigabit Ethernet link -and a lot faster than the consistent 25MB/sec I used to get on exactly the same hardware when using Samba to do Linux-to-Linux transfers.

So NFS it is, then!

Not so fast! There’s the not-so-minor matter of configuring The Other Half’s Windows PC to partake in this feast of NFS-ness. As I mentioned, that’s running Windows 7… and it’s the Ultimate edition, which means an NFS client is readily available. All you have to do is go to Start > Control Panel > Programs and then select the Turn Windows features on or off option:

You simply find the Services for NFS item, expand it and select the two sub-options for activation. Once you’ve done that, you can then issue ‘mount’ commands on Windows that resemble their Linux cousins very closely:

The basic format of the command is simply mount server:/share/name drive_letter: …and in my case, it means my Music folder stored on the server’s RAID array is now accessible from the Windows PC by navigating to the M: drive in Explorer:

And this is the point where the good news abruptly ends. Sure, getting the NFS export seen and mounted by the Windows PC is a piece of cake… but as any fule kno, André Mathieu’s name is spelled with an ‘e-acute’ at the end of his first name, not a capital-A-plus-Copyright-symbol as Windows Explorer seems to think is appropriate. Arnold Schönberg will also be missing his O-umlaut and wouldn’t be impressed with his newly-acquired A-with-tilde-plus-paragraph-mark.

Of course, what we have here is ye olde and ancient trouble with extended Western European ‘foreign’ characters. It’s bugged me for years when doing Samba mounts (but is easily fixed there by specifying a utf-8 mount option when issuing the mount command). Now it’s back with a vengeance… and there’s nothing I can do (apparently) to fix it!

Here’s the real problem, from the Windows perspective:

The mount command on its own lists network drives which have been mounted and the options/attributes that apply to those mounts. The killer line here is lang=ANSI, indicating that Windows has mounted the network drive assuming that it will find only ANSI characters at the other end. When it then actually finds UTF-8 characters instead, it gets itself very confused, as we’ve seen.

Knowing this, it’s easy to speculate that there must be a way of specifying something like lang=utf8 when performing the original mount command and that this would fix the problem:

That’s me first unmounting the M: drive I’d created before and then attempting to re-mount it but with a utf8 language specified instead of the default ansi one. As you can see, however, “utf8″ is not an option that’s actually available for this parameter. You can certainly choose a variety of Chinese, Korean and Japanese character sets -and, of course, “ansi” is valid, but not “utf-8″ or anything like it.

As far as I could tell from reading the documentation that comes with the Windows 7 NFS client (go to Control Panel > System and Security > Administrative Tools then open the Services for Network File System (NFS) program and hit [F1]), there are no other mount options that can be specified which would have anything to do with getting the character set right. So, as best as I can tell, there is no fix for this problem… which is truly dumb!

Just to emphasize how silly this is, here’s the exact same Windows PC browsing through the exact same folders on the exact same server …only this time, using Samba:

The two Andrés have their acute accents, and Arnold gets his umlaut back… no problems at all.

For me, unless someone else points me in the direction of a fix, this simply means it’s back to Samba and boo-hiss to NFS, which is a shame as I would much prefer things the other way round.

There are, apparently, commercial NFS clients for Windows. I may have to try to evaluate one of those to see if the character set issues are surmountable, but I am not holding my breath. In the meantime, the freebie stuff from Microsoft on this score is functionally useless to me :-(

One thought on “NFS, Windows and Foreign Characters

  1. Pingback: Win NFS Fixed (at a cost) | Diznix Blog

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>