Out of the blue, your server stops responding. The screen goes gray for a moment, the machine restarts, and by the time you even know it happened everything is fine. Then it crashes again. This time you hear, “I just did a Spotight search on the XServe, and then everyone was disconnected…”

There is a known issue with OS X Server 10.4.7-11, where client machines can crash the server by remotely searching network volumes. The problem lies in how the operating system sets the memory buffer for disk usage. In servers with less than 4GB of RAM, the buffer is set higher than the amount of physical memory, so that searching a volume can fill the buffer and crash the machine.

You can see this happen on effected systems when Spotlight is used on their network shares. Open Activity Monitor in the Utilities folder (or usetop on the command line) and watch the main OS process (called kern_task) quickly take all the available memory.

The solution is simple, though it requires the use of a Terminal-based text editor and some familiarity with the underlying OS X file system. Open /etc/rc.server, and set the buffer to a smaller value, replacing 90000 with 20000 in the line below:

sysctl -w kern.maxnbuf=90000

You can also use the Unix “stream editor” to make the change with a single command. From the Terminal, simply type:

sudo sed -i.bak 's/maxnbuf=90000/maxnbuf=20000/' \
/etc/rc.server

Here sed searches for the phrase between the first set of slashes and replaces it with the phrase between the second. The -i option edits the file in place, backing up the original contents to a separate file in case there’s a problem. This approach works particularly well if you’re administering multiple servers with Apple Remote Desktop, as it can be sent to a list of machines using the “Send Unix Command” feature.

Once the file is changed, reboot your system to reset the buffer. This will solve the issue for the time being, but you’ll want to check after each Software Update to make sure the fix is still in place. Although Apple has reported this problem in it’s knowledge base since February, subsequent updates to 10.4 have all changed an edited /etc/rc.server file back to it’s original values.