Apple’s enterprise readiness

This post’s title may be completely wrong since the real subject is Samba. Well Samba server with a lot of Apple machines connected to it…
Let’s start from the beginning. Once upon a time there was a Samba/AFP share on an old Apple server. Since it was getting pretty old, its authentication wasn’t working very well and a central authentication server (Windows AD) was added, it seemed good to move all its data to a Samba server with AD integration.
Everything went fine, even with the synchronization of about 2 million files (taken also from other sources that were centralized).
But problems were about to come in few hours. One minor issue was the impossibility to connect from Lion computers that were planned to install in the next few days.
Apple couldn’t use new Samba versions with GPLv3 so it decided to rewrite from scratch the SMB protocol focusing only to the newer version 2.x. The previous version (used before Windows Server 2008 and Vista) was completely ignored.
Anyway this problem was easy to fix by upgrading to Samba version 3.6.x or using some other SMB client on Lion machines.
One really nasty problem came out the next day with the presence of weird characters in many filenames. The list of these characters was almost complete: spaces, slashes, commas, question marks, exclamation marks, stars, degrees, ampersands, brackets, square brackets and more.
Using some find and replace with regular expressions helped me to get rid of all of them. Then I started to tell every user (again) not to use some character at all for the filenames.
After some research I stumbled upon a huge page of Snow Leopard only problems (starting in 2009 and still active): a lot of people had the same issues I was having (slowness and disconnections), and not only with Samba but also with native Windows shares.
So I found out that some changes on Samba server configuration were also needed to better support OSX clients:

case sensitive = Yes

unix extensions = No

Caution if you use veto files option to remove hidden files like .DS_Store: OSX wants them and must be writable by any user. Also the proper way to get rid of named streams ._ (dot underscore) files is to disable them on every single client and not using a Samba veto configuration.
After all this work I thought that now everything should be fine. But it wasn’t.
Some users were still experiencing troubles accessing some files or even directories. I really had not the faintest idea of what it was happening. All I could see was the presence of accented characters in the filenames. Trying to replicate this behavior with new files, choosing strange and bad characters in their names, wasn’t of any help: everything went just fine. But working with the existing data (the one copied from the old OSX server) led to the solution. For example, if a directory containing an accented character was copied locally from the share, it could lead to errors or to an empty directory. Renaming it (from the shell, which did not displayed the accented characters) resolved the issue.
Ok, but how could I search and rename all of these characters if I wasn’t seeing them from the shell? And why this is a blocking issue (even if accented characters should be avoided from the start)?
After another accurate and detailed investigation I found three clarifying lines in the official Samba documentation about a tool, convmv, and filenames conversion.
I want to save this for myself and for anyone who might need it: the convmv man page part that, once read, made me curse Apple:

Filesystem issues
Almost all POSIX filesystems do not care about how filenames are encoded, here are some exceptions:
HFS+ on OS X / Darwin
Linux and (most?) other Unix-like operating systems use the so called normalization form C (NFC) for its UTF-8 encoding by default but do not enforce this.  Darwin, the base of the Macintosh OS enforces normalization form D (NFD), where a few characters are encoded in a different way. On OS X it’s not possible to create NFC UTF-8 filenames because this is prevented at filesystem layer.  On HFS+ filenames are internally stored in UTF-16 and when converted back to UTF-8, for the underlying BSD system to be handable, NFD is created.  See http://developer.apple.com/qa/qa2001/qa1173.html for defails. I think it was a very bad idea and breaks many things under OS X which expect a normal POSIX conforming system. Anywhere else convmv is able to convert files from NFC to NFD or vice versa which makes interoperability with such systems a lot easier.

Well, another nasty incompatibility from the Apple guys. Thank you. But then I knew what to do: run convmv and letting it change the UTF-8 encoding of all files and directories. The problems were all gone.
I think that there are really few statements from Steve Jobs that I agree but one, not made public, was about his disbelieve in macs for business. And, in my opinion, they are not ready and good for it yet.


This entry was posted on Thursday, April 5th, 2012 at 1:44 PM and is filed under apple.

You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.

Comments are closed.