dyld: shared cached file was build against a different libSystem.dylib, ignoring cache

On a Mac 10.6.8 server we were experiencing poor performance and erratic behavior from Server Administrator.  Looking at the Console Logs we found that it was filled with the following error:

dyld: shared cached file was build against a different libSystem.dylib, ignoring cache

Apparently this is a fairly common error in 10.6.x and can affect a wide variety of applications.  The fix is pretty straightforward.  Open Terminal and type the following:

sudo update_dyld_shared_cache -force

How to check if an Apple server is Kerberized against AD: verify Service Principals

If Mac clients are having trouble accessing a bound OS X server, check that the server is Kerberized against AD.  First, run the following command:

sudo klist -kt

You should see a number of service principals with the Kerberos realm of your.domain.com

Second, you need to ensure that the correct service principal is in use by the AFP service.  You can use the following command to do this:

sudo serveradmin settings afp:kerberosPrincipal

This should show something like "afpserver/@YOUR.DOMAIN.COM".   If it shows a value in the LKDC realm it is incorrect and will need to be fixed before you can connect using Kerberos.

Here's a command you can use to fix it:

sudo serveradmin settings afp:kerberosPrincipal = "afpserver/@YOUR.DOMAIN.COM"

"You are unable to log in to the user account [account name] at this time.

Problem:  an AD bound Mac shakes off login attempts and returns a message that says:

"You are unable to log in to the user account [account name] at this time.  Logging in to the account failed because an error occurred."

There are two things to to try:

First, update the Automounter master map as outlined in this Apple KB article:

http://support.apple.com/kb/TS3346

Secondly, if the user has a home folder path specified in their AD profile (Profile tab), remove it.

OS X Server: users can not connect to SMB or AFP shares

We have been troubleshooting several reports from offices with bound OS X servers where Mac and PC clients are unable to connect to shares using AFP or SMB.  Additionally these offices have reported that Macs will randomly drop their AFP connections to the OS X server.

When the connection problem occurs often times the server shares will display generic ACL GUIDs: a series of numbers and letters instead of the group name.   In cases such as these restarting Directory Services generally resolves the problem- at least temporarily:

sudo /usr/bin/killall DirectoryService

Other times the GUIDs display normally but the connection problems still persist.  In these cases two things are suggested:

1. Nest AD users into local groups and then use the local groups to populate the ACLs
2. Flush the group membership cache by running this command:  

sudo dsmemberutil flushcache

Generally these problems occur most often on Leopard servers- Snow Leopard servers have improved group membership caching.

How to force a 10.6 client to generate a Kerberos ticket at login

Refer to this Apple KB article:

http://support.apple.com/kb/HT4100

You need to add the string:

builtin:krb5store,privileged

Under the key:

system.login.console

In the /etc/authorization file

Generating a kerberos ticket from the command line in OS X

kinit [user name]

You will be prompted for the user's password

Bound Leopard Server not allowing SMB or AFP connections

Problem:  A 10.5.8 server was not allowing SMB or AFP connections.  The server was bound to AD but "id" commands were failing- sometimes.

Looking at the logs I saw that they were filled with launchd errors:

 com.apple.launchd[1] (org.openldap.slapd): Throttling respawn: Will start in 10

These were causing very, very poor performance and pretty much preventing Directory Service from operating; that in turn prevented any logins.

The first thing I attempted was to unbind the server but as it couldn't connect to the domain I did a Force Unbind, deleted the edu.mit.kerberos file and the Directory Services folder and restarted.  I then re-bound the server and immediately unbound: this ensured that the server's AD account would be removed.

From the unbound server I took these actions:

• Changed the Windows role to Standalone server
• Stopped the SMB services
• Opened Terminal and ran "sudo –s /usr/libexec/slapd –Tt"

This returned:

could not stat config file "/etc/openldap/slapd.conf": No such file or directory (2)
slaptest: bad configuration file!

I then viewed the contents of the directory:  cd /etc/openldap/ls

There was no slapd.conf file present but there was a slapd.conf.default file so I renamed  it: "cp slapd.conf.default slapd.conf"

I then re-ran the slapd command:  "/usr/libexec/slapd –Tt" and it returned:

bdb_db_open: Warning - No DB_CONFIG file found in directory /private/var/db/openldap/openldap-data: (2)
Expect poor performance for suffix dc=my-domain,dc=com.
config file testing succeeded

Since LDAPv3 is turned off in Directory Services this shouldn't be a problem

• Reboot 
• Launch Server Manager
• Change the Windows role to Domain Member
• Start the SMB service

AFP and SMB log-ins now worked.

These steps and more info can be found here:  http://discussions.apple.com/message.jspa?messageID=10613310

Target booting an Xserver to install from another computer

We found ourselves in a situation where we were unable to install from the optical drive on an Xserver.  We used the following steps to resolve the problem:

1. Attach a FW cable between the Xserver and another Mac (we used a Mac Book Pro)
2. Insert the Server Install DVD into the remote computer
3. Turn off both devices
4. Restart the remote computer in Target Disk Mode (holding down the "T" key)
5. Restart the Xserver holding down the Option (alt) key and select the remote install drive as the startup disk
6. Continue with the install normally

It is VITAL that you do not target boot the Xserve onto the client: put the client into Target Disk Mode first!

After a re-IP of an Xserver, XP clients could not log in using SMB

An office moved locations and in so doing upgraded their DC to Windows Server 2008 and also change the IP of their Tiger (10.4.11) Xserve.

After completing the process, XP users were unable to log into the Xserve using SMB.  AFP connections were unaffected.

After many long nights of troubleshooting and searching through server and WireShark logs we were still no closer to a solution.  A Leopard server was built at the location to test and it initially had the exact same problem.

To get the test Leopard server to work we had to follow the steps outlined below and replace the smb.conf file with the smb.conf.template file.  After doing these steps, SMB connections to the Leopard server were successful.

During the entire process we were working with Apple and they built Tiger, Leopard and Snow Leopard servers in their environment to see if they could reproduce the problem- the could not.

Apple felt that contrary to our initial assumptions, changing to a 2008 DC did not cause the problem.  Rather the re-IP of the Tiger server broke SMB authentication.  They could not pinpoint the problem exactly but suggested we follow these steps to resolve the problem:

1. Change the role of Windows to Standalone server.  Stop the Windows service.

2. Unbind from Active Directory.

3. Run the changeip script and change the IP address in System Preferences/Network.  Restart the server.

4. Run the command "sudo changeip -checkhostname".  If everything is correct, bind the server to Active Directory.

5. Change the role of Windows to Domain Member and start the Windows service.

6. Verify the SMB shares are configured correctly (I created a new share).

7. Have XP clients connect to the 10.4 server.

Unfortunately, the problematic Tiger server wouldn't allow us to complete the tasks- failing on step 5- changing the role back to a Domain Member. 

At that point it was decided to re-build the server as a 10.5.8 Leopard server.  14 hours later, we finished the job!  There were problems with the mirrored set in the Xserver which forced us to break the RAID and install on a single physical drive.

We were finally successful at re-building the server and when we were done XP clients could connect using SMB and get single-sign-on.

One nice thing: because we only rebuild the Xserver and not the fiber channel RAIDS attached to it, all the AD file and folder permissions were retained.  This saved us a huge amount of time by not having to re-perm all the shares!

Changeip command for updating IP and host names: OS X Server

If you need to update the IP address or host name on an OS X server you need to do a changeip command:

First do sudo changeip –checkhostname to see what the true host name is.

You can then change the IP and the host name in one fell swoop:

Sudo changeip - [old IP] [new IP] [old host name] [new host name]

ex: sudo changeip - 100.192.46.10 100.192.46.12 oldserver.mynetwork.com newserver.mynetwork.com


If you just want to change the IP then leave out the host name part.  If you want to change only the host name you still must put the IP addresses- even if they are the same.

On the sever open a Terminal window and type “man changeip” for a good rundown of the command syntax and parameters.

Here is a link to the man page. 

OS X Server: Speeding up directory searches

One of the major complaints about OSX Server is that once they are bound, searching for users/groups from the AD can take a long time (and sometimes times out before completion).

The problem, according to Apple, is that AD doesn’t index any attributes for a substring search and therefore all records have to be searched. The Workgroup Manager plug-in times out after 60 seconds and even an ldapsearch from the command line will only search for 120 seconds and then give up.

Apple has two suggestions to speed up searches:

• In Workgroup Manager, click on the little magnifying glass in the search window and select "Name is" and enter the last, first of the user you are searching for
  

• In Workgroup Manager, click on the little magnifying glass in the search window, go to “advanced” and search for “Real Name” This will search the cn attribute and is much faster than a normal search- this works for groups too

I have tested both of the above work-arounds and found that they work very well. The Real Name search is particularly fast.