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:
The same types of modifications can be made to the “allow file-read*” section, enabling
collabpp access to the two
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*”:
The profile includes a line for
libpq.5.4.dylib, but not for
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:
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 .