Password-less Samba on Fedora 25

I recently needed to allow a Windows server to access some files which were stored on my Fedora 25 PC. I could have used NFS, but for reasons passeth understanding, I decided to do it with Samba instead -and immediately discovered that my knowledge (or, rather, recollection) of Samba is a bit rusty these days! Sharing stuff is relatively easy to do… but doing it in the context of a PC that uses a firewall and SELinux was definitely not trivial.

So, on the grounds that Fedora 25 has 2 more days of life in it yet; and recognising that I need to remember this stuff from time to time, I wrote the inevitable short piece on the subject.

Understand, I’m not trying to be subtle about it: I wanted anyone to be able to do anything in the Samba network share, without being asked for usernames or passwords. This isn’t the sort of configuration you are likely to want in any production setting I can think of, but for a home network under my total and sole control, I figured it would do!

In any case, the new short article is here.

Furriners!

So, last time I promised a tale of woe and skulduggery regarding my Solaris Samba shares.

Let’s assume I’ve created a new share, called “bulkdata”, on a freshly-built Solaris box as per this article.

On Windows, I can connect to the share without problem and set about creating a new text file like so:

lorem

Note that the file is called Götterdämmerüng.txt, so it contains three pesky ‘foreign characters’ to start with. The contents of the file are also riddled with foreign characters: genügte as the seventh word, for example. Then it goes completely bonkers as I slip into fluent simplified Chinese!

As you save that in Windows 7, Notepad gives you some options:

lorem02You can choose to save in ANSI (the default), Unicode or variations on Unicode. Given what my Solaris box is telling me:

lorem03…it would seem that selecting that ‘UTF-8’ option would make sense, though it’s a bit of a pain that it’s not the default. Fat chance of getting ToH to remember to alter the encoding every time a new file needs copying to this server! But I’ll give it a go anyway… UTF-8 it is.

Once saved, here’s what I see on the server itself:

lorem04

Excellent news! The file is there, complete with its set of three foreign characters. We have end-to-end foreign character awareness, with not too much effort!!

Or do we? Let’s just check the contents of that file, shall we?

lorem05

Well, genügte is there, in all its umlaut-y glory, so we certainly have end-to-end European foreign character awareness… but sadly the Chinese will have to use some other Samba share, because this one clearly chews this stuff into oblivion.

Or does it!

Assume for a moment that I’ve just had a mental breakdown and decided that I prefer using vi to nano:

lorem06

Different text editor…same file…same contents… only now the Chinese is perfectly cromulant (and the German remains so too).

And just for laughs:

lorem07

So the operating system’s own cat command also has no trouble displaying the simplified Chinese, nor the accented German. Just nano, apparently.

How about I step back a bit, and save that file in the default Windows format, though? That would be “ANSI”. I’ll save the same file in that format in Notepad as götterdämmerüng2.txt. Doing so prompts Windows to warn you:

lorem08

…but if you persist by clicking [OK], the file arrives at the server in one piece and looks pretty good in vi:

lorem09

OK, we really have lost the Chinese at this point, but the German is still sufficiently umlaut-y for me to be happy. Except it’s vi, and I prefer nano:

lorem10

…and nano loses the umlauts and the Chinese.

And the OS itself is none too happy, either:

lorem11

It seems to know there’s something where there ought to be an umlaut, but can’t bring itself to display the right character at the right time.

The same thing happens in Linux, by the way, if it happens to be a client of the same Samba share: nano glitches on the umlauts (and loses all the Chinese) whereas vi copes with the umlauts (but also loses all the Chinese… ANSII is not good for that sort of character set!). Linux’s cat command also behaves the same way as nano: umlauts appear as strange question-mark lozenges.

This sort of things has bugged me for more years than I care to count (OK, for 18 years if we have to, since I first started ripping Italian and German opera to MP3 files that had to be named correctly, in 1998). I never ceased to be amazed at how the damned problem still hasn’t been sorted out completely as yet: UTF-8 was supposed to make this stuff go away a long, long time ago.

For many years, my battle was Linux v. Windows: Windows file names containing accented characters would be garbled on the Linux end of things, unless I remembered to add the ‘utf8’ mount option in /etc/fstab. It only took me 5 years to work that one out!

But Solaris is a bit more insidious even than that: it gets the display of things right at the OS level straight away… but then scrambles the contents, depending on what application you choose to use!

I guess the moral is: watch what clients you use and how they save their data… and clearly, vi is the better text editor 🙂

DIY NAS

I have spent most of the beginning of this year re-building my two NAS servers …and then re-re-building them because I wasn’t happy with their performance or some other configuration peculiarity. Not a speedy job when each rebuild requires you to move off 6TB of data and then copy it back when you’re ready!

My biggest problem was getting the RAID stipe alignment right: I cunningly used command line-fu to start partitions at various cylinders to try and get it right, but performance figures suggested I’d got it horribly wrong instead. So then I re-did them using the simple GUI tools provided… and everything worked beautifully. On this occasion, then, GUI 1, CLI 0.

But the job is finally done, and I now have a minimalist CentOS 6.3 purring away on both boxes, one being a mirror of the other and with decent read performance, which is the main thing.

I figured it would be useful not to forget some of these painfully-learnt lessons, so I wrote up the installation and configuration process as a new article.

At some point this year, I will start replacing the drives used with new 3TB WD Red drives… At least I’m now confident that things should be plain sailing at that point.

Win NFS Fixed (at a cost)

Further to my last post, in which it was discovered that the NFS client tool included in some editions of Windows 7 can’t cope with accented characters (or anything not in the standard American view of the alphabet, really)…

The good news is that I have a fix. The bad news is that it comes in the form of a commercial NFS client, called ProNFS, which costs US$40. That’s at least $15 more than I feel entirely comfortable paying, but there’s a 30-day trialware edition that at least you can test stuff out with before you part with your hard-earned moolah.

Crucially, in the client settings tool that is provided as part of the ProNFS software stack, there’s this little dialog box:

Spot the reference to using UTF8 file names! Woot!

Once you then use the ‘map drive’ tool to find your NFS shares and mount them as a standard windows drive letter affair, everything works as advertised on the tin-lid:

Spot all those European names displaying correctly, replete with accents, umlauts and cedillas! Problem solved, I think.

I do have a few “issues” with this approach to solving the problem, though. I suppose the first one is simply this: “if they can do it, why can’t you, Microsoft?!”. The second is that the installer for this program looks like it was written in 1994 and hasn’t been updated since! There are lots of little touches on the company’s website, for example, that make me nervous -constant references to the software being compatible with Vista, for example, with never a mention of Windows 7. If you check out their promotional screenshot, too, it will seem as if the software hasn’t been updated since 2003! They’re shooting themselves in the foot there, because if you actually run the NFS server component today, it will report version 1.6 with a compile date of June 23rd 2011, which is much more reassuring! Finally, there’s the not-so-minor matter of the Blue Screen of Death I got when I removed the evaluation version and performed post-removal reboot. I haven’t seen one of those for years, so getting one as the software is removed didn’t fill me with warm glows and kindly feelings!

In the end, though, such things are probably not major issues. I should say in fairness that once the software was installed and running, it behaved itself perfectly -and I can live with slightly out-of-date documentation and promotional wares so long as the software behaves itself. Yes, I could wish it were a tad cheaper, but even at US$40, if it means I don’t have to configure Samba, it’s probably just about worth it! Colour me happy, ish.

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 (<b>/etc/exports</b>) 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 :-(