Tackling Apparent Bugs in the Mountain Lion Server Wiki Service

Photo of Greg
Photo by Jeff Kubina - http://flic.kr/p/4hz5Re

Straight out of the box, the Mountain Lion Server wiki service — externally smooth and polished though it may be — appears to be one of Server.app’s single biggest sources of errors and warnings written to the logs. Should you try to ‘fix’ them or let them be?

Bugs, Bugs, Bugs

Personally, I’m baffled by the state of the wiki server in OS X Server. In my experience, even the most basic, plain vanilla usage of the wiki server — on the main domain only, with WebDAV turned off — yields copious quantities of sandboxd error messages in the logs, all involving collabpp and repeating every five minutes, which is the launch interval for collabpp. I’ve experimented with clearing a few of these sandbox errors by editing the collabpp sandbox profile to grant read permissions to particular files (as I describe below) — only to discover that if too many of these errors are ‘fixed’, then deluges of other errors come in their place.

All of which is to say something is distinctly flaky here.

The sandbox is supposed to protect the system from faulty program logic, not be relied upon as a provider of external limitations on part of an application’s normal operation. Therefore, either the wiki service and/or some of the underpinnings it relies on are suffering from distinctly faulty program logic, or they’re inappropriately relying on the sandbox to prevent them from doing things that they should not be attempting to do in the first place.

In my own case, the wiki service is not a big deal — I do use it, but not for anything remotely mission-critical. I would urge quite a huge spoonful of caution when using the wiki server; quite apart from the oddness of including a /wiki/ index in every virtual host created, yet not providing any actual wiki service to those hosts, there are other peculiarities and apparent bugginess afoot. (To enable the wiki service on other virtual hosts, see the earlier article: “How to Enable Wiki Services on Multiple Virtual Hosts with Mountain Lion Server”.)

And last but not least, you may find that upgrading to the 2.2 revision of Server.app whacks the wiki service in other new and exciting ways, apparently tracing back to collabd‘s inability to get a database connection. Apple made some changes to Postgres storage with the 2.2 update, and this may be related. You may be able to clear this problem by first shutting off the wiki service, then manually ensuring that Postgres is running using the following command, and then re-enabling the wiki service:

sudo serveradmin start postgres

If that does not take care of the problem, my only suggestion is to restart the server.

Experimental: ‘Fixing’ Sandbox Errors, Especially Prior to OS X Server 2.2

As I mentioned above, even the most basic, plain vanilla usage of the wiki server — on the main domain only, with WebDAV turned off — yields copious quantities of sandboxd error messages, and for some reason the error messages explode into even larger quantities when assigning wiki permissions based on groups:

sandboxd: collabpp deny file-read-metadata /Library/Keychains

sandboxd: collabpp deny file-read-metadata /Library/Keychains/System.keychain

sandboxd: collabpp deny file-read-metadata /Library/Keychains/apsd.keychain

sandboxd: collabpp deny file-read-metadata /Users

sandboxd: collabpp deny file-read-metadata /private/

sandboxd: collabpp deny file-read-metadata /private/var/teamsserver

sandboxd: collabpp deny file-read-metadata /private/var/db/mds/system/mdsObject.db

sandboxd: collabpp deny file-read-data /Library/Preferences/.GlobalPreferences.plist

sandboxd: collabpp deny file-read-data /Library/Preferences/com.apple.security.plist

If you’re feeling adventurous and want to attempt to clean up some of this mess repeating like clockwork every 300 seconds, you can edit the sandbox profile for collabpp. There is no .sb file associated with collabpp anywhere in the usual /usr/share/sandbox, but we can find it here instead:


Interestingly, at the bottom of that profile, you can see many of the above explicitly set for ‘deny’ — but commented out. It’s almost as if someone had been doing some testing, explicitly denying access to various resources, then commented those out, but forgot to enable access explicitly. In any case, given this continual spew of sandbox errors into the logs, something seems half-baked. (Perhaps, as with the .AppleSetupDone problem mentioned below, access is being denied specifically to shut off some activity that really ought to be shut off — but if that’s the case, then isn’t there a better way to accomplish it than with a crude sandbox sledgehammer that leaves a trail of broken processes sprinkled through the logs…?)

If you’d like to eliminate the errors, you can do so by editing the collabpp sandbox profile directly and adding new lines covering each of the relevant locations to the appropriate section. For example, in the “allow file-read-metadata” section, you can experiment with adding:

	(literal "/Library/Keychains")
	(literal "/Library/Keychains/System.keychain")
	(literal "/Library/Keychains/apsd.keychain")

And so on. Note that for nested directories like /private/var/db/mds/system..., you would need to explicitly enable access to each level of the directory hierarchy. For the /Users directory, on the other hand, you may wish just to enable it with the following instead:

	(subpath "/Users")

The same types of modifications can be made to the “allow file-read*” section, enabling collabpp access to the two .plist files.

After modifying the sandbox profile, you’ll need to restart the server for these changes to take effect.

Note that in making these modifications, you are messing with the guts of Server.app itself. It’s good practice to keep a backup of anything you change in there, so you can roll it back immediately at the first sign of any problems. And, of course, the contents of this file may change with future updates — hopefully the contents will change, and wiki server will work correctly without generating floods of error messages. (Note that even the syntax of the file may change, as Apple makes clear in comments within other sandbox profiles.)

‘Fix’ Sandbox Errors, Even After OS X Server 2.2 Update

Although some of the errors outlined above may have been fixed with the 2.2 release, many remain, while new ones have appeared. For example, you may find it useful to experiment with adding the following to “allow file-read*”:

	(literal "/Applications/Server.app/Contents/ServerRoot/usr/lib/libpq.5.5.dylib")

The profile includes a line for libpq.5.4.dylib, but not for libpq.5.5.dylib.

Now as far as I can tell, each of these modifications helps something to work that otherwise was not working as intended (at the very least, that is true with the proviso “unless it was intentional to write reams of errors and warnings to the logs”). However, here’s another one you may be tempted to ‘fix’ to help quiet another deluge of errors that otherwise appear in the logs every 300 seconds:

	(literal "/private/var/db/.AppleSetupDone")

My suggestion? Don’t fix it.

Why? Because, as far as I can tell, once this is done, the com.apple.collabd.preview launch daemon will begin launching every 300 seconds and trying to talk to the windowing system — even when nobody is logged in. When nobody is logged in, that generates a cascade of errors for collabpp and ultimately for a launch services lookup performed when reporting the crash, plus a full saved crash report for collabpp. Yes, a nice full crash report saved for you every 5 minutes — that’s 120 per day, in case you were wondering. So, it’s probably better to see the following every 5 minutes than to generate a full crash report every 5 minutes:

sandboxd: collabpp deny file-read-metadata /private/var/db/.AppleSetupDone

Unless you like that sort of thing…

All material on this site is carefully reviewed, but its accuracy cannot be guaranteed, and some suggestions offered here might just be silly ideas. For best results, please do your own checking and verifying. This specific article was last reviewed or updated by Greg on .

This site is provided for informational and entertainment purposes only. It is not intended to provide advice of any kind.