Mac OS X SIG

Like many universities, we use OpenLDAP for our central directory system. As you might guess, the hostname for this system is ldap.stanford.edu. This is actually a DNS pool, though. There are multiple machines offering the same service. There's ldap1.stanford.edu, ldap2.stanford.edu, ldap3 and so on.

When I configure a Mac to use an external directory system, it's usually our OpenLDAP directory. Using Directory Access.app in the Utilities folder (or the command line equivalent, dsconfigldap), I usually enter that hostname, ldap.stanford.edu. However, there are limitations to this.

At some point during configuration, the Mac connects to the DNS pool, gets sorted to one of the physical machines, does a forward name resolution, then uses that numerical IP address for subsequent connections.

Here's the rub: if the IP address of that specific host changes, things break.

Occasionally, I get a call that my Windows users connected to my Samba server on Mac OS X Server 10.5 can't manipulate a file. They get various errors when trying to open or download the file. The problem seems to be random but consistent; some files show problems, others are fine — even in the same directory.

Consider whether the problem is related to Windows NTFS alternate data streams (ADS). (See also the Wikipedia article.) You can see whether this is the case using the Terminal.

The extended attribute is the :ZONE.IDENTIFIER:$DATA part and needs to be whacked off. It's expendable. One command uses the xattr command. (Note that you'll need to escape the dollar sign.)

There are (at least) two additional ways to handle these.

When configuring Samba 3 to hide Mac-specific directories from Windows users, I typically edit /etc/smb.conf on my Mac OS X Server, using either

veto files =
hide files =

This worked fine — until it didn't. Seems I wasn't doing it properly.

There's a lot of (typically legacy) HFS detritus sprinkled around on a Mac server. When both AFP and SMB are enable, Windows users see these bits and pieces, much to their confusion. (These files and directories are invisible to Macs.)

Originally, I had this at the end of my smb.conf file, but once I added the final veto files = option below at the bottom, I was disappointed things didn't work as expected.

It seems I was incorrectly adding the files and directories in my smb.conf file. That last line refers to a directory that has a space in the middle. When I did a

they still were there, staring out at me. (By the way, I'm not confident in the smbcontrol reload-config command, since smbd is controlled by launchd on a Mac. I just do a quick severadmin command.)

NB: The slashes have nothing to do with the filename or with a path. See this entry in the SMB book from O'reilly. They're there just so smbd properly parses out when an entry starts and ends. But it's the space that tripped things up.

So it seems what I needed to do was to group all the files and directories into one line, like what's below.

That was the trick. I'm not sure why, because seemingly the individual entries should work just as well as the string of filenames. Now those Mac filenames are now hidden from my Windows users.