December 2007

Since I had CentOS 5 up and running on ESX Server in the test lab, I decided to try to validate my latest Linux-AD integration instructions on this installation.  Unfortunately, the instructions do not seem to work well at all with CentOS 5; here are some of the errors that I ran into:

• When using “net ads join” to join the Active Directory domain, it didn’t recognize any existing Kerberos tickets.  I’d already run a “kinit <AD username>”, but “net ads” continued to either a) try to use the root account if I didn’t specify the “-U <AD username>” parameter, and b) prompt for password even when I’d already obtained a Kerberos ticket for the specified username.
• When initially trying to join the Active Directory domain, “net ads join” threw this error:
  [2007/12/04 12:57:08, 0] libads/kerberos.c:create_local_private_krb5_conf_
for_domain(594) create_local_private_krb5_conf_for_domain:
failed to create directory /var/cache/samba/smb_krb5.
Error was Permission denied
  This error persisted until I manually created the /var/cache/samba/smb_krb5 directory myself.  Why this directory wasn’t created automatically during the Samba installation is beyond me.  Once I created that directory, the error went away, but Samba still wouldn’t create the keytab or add entries to the keytab.
• The “net ads keytab” command failed miserably; it would not create a keytab, nor would it add entries to a keytab.  No error message is reported; it just doesn’t work.

I inquired on the #samba IRC channel on irc.freenode.net, but the only person willing or able to respond didn’t have any information to provide (in fact, he’d actually used my Solaris-AD integration instructions as a guide for some of his own work).  Various Google searches also failed to provide any helpful information.

By the way, these tests were performed on a stock installation of CentOS 5, with all the latest packages installed using “yum update”.  The Samba version was 3.0.25b-1.el5_1.2.

In the end, I’ve given up on trying to make Samba work in the AD integration process and will instead fallback to the use of ktpass.exe to create the keytab file.  If you have any useful information to share, please let me know or post it in the comments.  Thanks!

I was reconfiguring NFS on the Windows Server 2003 R2-based file server providing both CIFS and NFS storage to the lab at the office when I ran into a strange issue.

I had started configuring some NFS exports, testing them to ensure that they worked as I expected.  Along the way, I decided I wanted to restructure the directory hierarchy I was using, so I deleted the folders and rebuilt them from scratch.  When I went to re-export one of the folders via NFS, a very non-descriptive and non-helpful dialog box popped up, indicating only that “the alias specified was already in use”.

I immediately suspected the NFS services, but no amount of restarting the services or the whole server would fix the issue.  The NFS server management console was not useful; it does not provide a list of current exports so that you can see where you may have already exported a path and used an alias.

After a few minutes of messing around, I recreated the original path.  Upon immediately recreating the bottom-level folder, it immediately became an NFS export.  What had happened was that I had created a folder, exported it, and then deleted the folder without removing the export.  The export information stayed in the Registry (location below) even when the file system location was not present.  In addition, the service did not log any information to the event logs indicating that a folder was missing or couldn’t be found.  The only error was the “specified alias is already in use” dialog box that appeared when attempting to export a different folder with the same name.

Upon digging around in the Registry, I found this location for NFS export data:

HKEY_LOCAL_MACHINE\Software\Microsoft\Server for NFS\CurrentVersion\Exports

Under this key is a zero-based list—where the first export starts as 0—that contains the NFS export information.  I deleted the key and now exporting the new folder with the original alias works as expected.

I suppose this behavior is expected; after all, the NFS server can only export a single path with any given name.  I just expected more information to be available somewhere along the way, be it a warning in the Event Log that states the exported path is no longer available, or a message in the dialog box that indicates what path is currently exported with the desired alias.  If the export was created months or even years ago, or created by a different administrator, it would be impossible to know where to look or where to go without digging into the Registry.  If Microsoft wants to continue to warn users about directly modifying the Registry, then they’d probably better provide some non-Registry tools to manage this stuff.