Recently had a request for help from a client who could not add a new user to their Open Directory. I Googled around for a while before finding an answer that was easier than rebuilding all of Open Directory and its accounts.
Error: eDSRecordNotFound
Solution: Get Open Directory to restart by turning the SSL option on, then off again.
After this, the user could be added normally. The error did not occur.
An update to my earlier post on this problem: if you have a Mac running OS X Server 10.5.8 or 10.6 and it has more than one network connection to a subnet, it will see itself when it checks for other servers with the same serial number.
Apple has fixed it for 10.5.8 and 10.6.
http://discussions.apple.com/thread.jspa?messageID=10396995#10396995
Apple fixed this problem in the “Mac OS X Server 10.5.8 Update v.1.1″.
<http://support.apple.com/downloads/Mac_OS_X_Server_10_5_8_Update_v_1_1>
The “Network Registration Update” for 10.6 fixes it.
<http://www.apple.com/downloads/macosx/apple/macosx_updates/networkregistrationupdate10.html>
The 10.6.1 update contains the fix as well.
details here: <http://www.apple.com/downloads/macosx/apple/macosx_updates/macosxserverv1061update.html>
Today I had a problem which I thought was related to having the extended attribute com.apple.quarantine on a folder with a large number of files and subfolders.
In the end, I had removed the quarantine from them all (topic for another post). It wasn’t the source of the problem at hand, but it did wind up with an important lesson: remove quarantine from any .zip file before decompressing it. Apple’s “Archive Utility” (the program that does the decompression) will maintain the quarantine attribute through every file, directory, and sub-directory.
If you’ve got a directory with a huge number of files set with this, look for my blog post on removing them all.
After helping the great folks at my daughter’s school with an external monitor issue, it seemed the problem was in the Mac itself. So naturally, questions about the status of the warranty came up. I knew that all the Apple Authorized service centers can look up the status, but getting someone on the phone isn’t necessarily easy or convenient (especially during off-hours.)
So, Googling (sp?) for the answer turned up a page I had not found before (ok, I had not really looked in a long time) : https://selfsolve.apple.com/GetWarranty.do
You can put in your serial number and get an answer immediately about the status of your warranty.
Things to know:
It can be a real pain to find and read the really tiny serial number sticker on a modern Mac, iPod or iPhone (or maybe its just my eyes going downhill). Much easier, you can copy and past the serial number from the “System Profiler” utility. Its in the “Hardware Overview” information which comes up first by default. You can find the System Profiler in the “Utilities” folder in the “Applications” folder, or you can go to the Apple Menu, select “About This Mac”, then press the “More Info” button.
If you bought an AppleCare extended warranty, but the site only shows a 1-year warranty, it may be that the extended warranty didn’t get registered. (The registration instructions should be in the box.) It may or may not have been automatically registered if you bought the computer and AppleCare together at an Apple Store. You have to buy an AppleCare extended warranty while the original 1-year warranty is still good. If you bought it, but didn’t register it, you may have to call Apple or talk to someone in an Apple store and show them the purchase receipt showing both the Mac purchase and the AppleCare purchase. Someone can then re-instate the extended warranty.
Here’s an interesting problem. It makes you kind of wonder how many different things you need to test for when working on software.
Today I got a call about an XServe having problems serving files. People had been getting errors that said no more connections could be made to the file server. Well that didn’t make sense. The server had an unlimited client license. But a quick check showed that this was the error being received and that 10 clients were currently connected.
Eventually, it occurred to me that 10 clients was the limit for developer or demo licenses (set by the serial number) so I went to check the number to see if something had gone wrong. Selecting the server itself in the list on the left, then “Overview” from the toolbar, I see red text that says “Invalid Serial Number“. Selecting the “Settings” icon in the toolbar, then the “General” tab that appears (because I already know where to look for the serial number), I see: “Invalid Serial Number: duplicate serial number“.
Now my favorite tool, Google, does well for me now that I know what to ask for. I quickly find this discussion on an Apple forum about this very problem. It reveals that the problem occurs on Mac OS X Servers that have more than one connection to the network on the same subnet, like this one.
Since the double-network setup was to get more network performance for FileMaker and file services, its good to note that the discussion points out Apple articles on suggested methods for combining ethernet ports and link aggregation. I haven’t had time to fully figure out how these suggestions will work with off-the shelf switches, so it looks like I’ll have another entry soon.
So, open suggestion to Apple, Inc: It would be nice to have a major error like an invalidated serial number presented to the user or admin a bit more prominently. Perhaps an automatic email about such a change in status, or a notification from the Server Admin application?
Well, a “fun” day with an Apple X-Server that bears repeating (well, writing down). If your server suddenly stops functioning with no real changes worth noting, you know its going to be an interesting day.
I got called in by a friend and fellow consultant. He told me that the X-Serve would be connected to the network for a short while and then stop. He could make it work by disconnecting the ethernet cable and re-connecting it. That made MacOS reset the connection and it would work for a short while.
After looking over endless settings, preference files, notes online, and a call to Apple support, we were left with the conclusion that we should re-install the OS (reluctantly). This is really something we did not want. (And felt that this was like surrendering, but, being the biggest stick we could hit it with, we thought this would fix it.)
WRONG! After re-installing and following all the instructions from documents, setup wizards and Apple’s instructions from the phone call, IT STILL DROPS OFF THE NETWORK.
In a moment of inspiration (desperation), I thought that the problem might be with the router (a current-model Apple Airport Extreme base station) or with some other equipment hooked up to it all. So it was time to start testing the network.
I started up a TCPDump job on the X-Serve to see if it showed something noticeably weird. There was quite a bit, but the only noticeable was the slowdown in packets once it dropped off the network. One thing that was strange; once the X-Serve could no longer load a web page and no desktop could connect to it, I could still successfully PING the X-Serve from my laptop. WHA?!
OK, at some point, I noticed that “arp -a” on the X-Serve would return a strange entry for x.x.x.255. (Something like ff:ff:ff:ff:ff if I recall.) This seemed symptomatic of the problem, but deleting it accomplished nothing. But AHA! the result of arp -a on my laptop showed that the X-Serve’s IP address was associated with an INCORRECT hardware address (M.A.C. address).
SO! There’s ARP poison coming from somewhere. (Or some kind of hiccup in the Airport.) So, in short order, we disconnected EVERY other device in the network except the DSL modem, Airport and X-Serve. But it STILL happens! We even replaced with the Airport with a brand-new spare of the same mode. (Which happened to be there for expansion plans.) It was STILL getting dropped! (Now we know its a good bug-hunt.)
The last bit needed to root it all out; that bad MAC address. It was always off by 1. The X-Serve has two ethernet connectors, and the information utilities show the two MAC addresses. In this case, they ended with :b0 and :b1. However, whenever the X-Serve dropped its connection, the arp entry on the laptop show the number, but ending with :b2. Resetting the X-Serve connection with the ethernet cable unplug/plug trick would immediately cause it to show as :b0 on the laptop until the next drop.
Well, one more quick call to Apple and we find out that the X-Serve has two EXTRA MAC addresses for the Lights-Out Management (LOM) system. And yes, they are :b2 and :b3 for this X-Serve. This was something I hadn’t realized because I hadn’t looked into using LOM before. In fact, when I went through the setup wizard after the re-install, I had specifically opted out of setting this up.
A quick trip to the Server Monitor program gave it all up. We set it to monitor the X-Serve, used the Server menu’s “Configure Local Machine” option to show LOM and yes, LOM ports 1 and 2 had been configured with the SAME IP address as the manual configuration we specified in the wizard.
So, whenever LOM would do something, the ARP table in the Airport (and any other computer listening) would be updated with the wrong MAC address. (Kind of like ARP poison I suppose.)
A quick change to the LOM settings and all was well. A minute or two later, and I had ARP entries for both the MAC addresses with their separate IP addresses. And the X-Serve has been happy ever since.
Its strangely nostalgic. I recall working on the same problem many years ago (circa 1990 when the MacTCP driver for MacOS 6 had a “dynamic addressing” option. It would create an ARP poison situation too. It had been driving my group nuts and when we found the reason we were able to just set manual addresses for all the computers and keep everyone working with no more dropouts.
Now for some rest. 
Just got through wrapping my brain around OS X Server’s included iCal or CalDAV server. It was quite a struggle, but I got it to go for me. In the end, it was deployed at the customer’s office and was working well to give them a central calendar.