First off let me say that QRecall is truly TimeMachine for adults - exactly the solution I was looking for.

On my laptop I set up QRecall to backup upon volume connect and every hour after that. I did not start the backup immediately and pleasantly watched the scheduler wake up at the appropriate time - the volume being connected - and do the right thing. All of the verify, compact and merge actions went off without a hitch.

Except for manual captures I have not be able to get QRecall to run on desktop - nothing triggered by the scheduler fires. EVER.

My desktop machine is configured like this:
Macintosh SSD - my boot drive
RAID HD - my primary data drive, a Thunderbolt RAID

I set up a backup to start - for both volumes - when the backup volume is mounted and every hour after that. The usual verify, merge and compact actions. Since I want both to happen together I set both up to not start until the schedule fired - no immediate first save. Nothing fires. Ever.

There are tale tell signs that something is wrong.

For instance, attempt to immediate execute an actions results is "Action not scheduled" and "The scheduler service could not be contacted...". No amount of log out/in or rebooting causes a backup to kick off. Works fine on the single volume laptop...

For instance, I check the "Show in menu bar" option in the Monitor preference. This works fine on my laptop however on my desktop it never appears. Quit QRecall and restart it and the check next to "Show in menu bar" has disappeared.

That said, my home directory is on the RAID HD drive, not Macintosh SSD - a fully supported but oft unused capability of MacOS. Perchance does the scheduler expect home directories to be on the boot volume? If so, the necessary files containing the schedule information are not there, they are RAID HD. Locating my home directory should just work - there is an official "NS" service to obtain such a datum - but if not used what I observe can occur.

At this point I am unable to get QRecall to work on my desktop and so I am requesting help.

-- mark

Mark,

Thanks for posting your problem. (I also got your message via email, but I'll respond here.)

First, try sending a diagnostic report from the desktop computer you're having problems with (in the QRecall app, choose Help > Send Report...). Also open up your Console app. In the system.log, filter the output with "qrecall", copy anything that pops up, and send those to me too, either via email or in the comments of your diagnostic report.

I suspect, however, that your problem is permissions. The issues you describe ("scheduler service could not be contacted" and "Show in menu bar" not working) all depend on background processes. QRecall installs several, but the two key ones are the QRecallScheduler and the QRecallMonitor.

These processes are installed and registered with OS X's launchd service in your ~/Library/LaunchAgents/ and /Library/LaunchDaemons/ folders. For security reasons, launchd is extremely picky about the location, ownership, and permissions of these folders. If they are anything except what launchd expects, it will refuse to launch anything installed there. (launchd will complain about this in the system.log, which is why I had you look there.)

My first suggestion would be to run the "Repair Disk Permissions" function in the Disk Utilities app, launch QRecall again (to reinstall), and then restart your system. If your QRecall monitor appears in the menu bar, I suspect your troubles are behind you.

If that doesn't fix it, write/post again and we'll get more specific in the investigation.

For anyone wondering, Mark and I went back and forth, over the course of several days, trying to figure this out. Mark was really helpful in getting to the root of this problem, and I thank him for his persistence.

It turns out, Mark had relocated his home folder to a different volume and that volume was set to ignore ownership and permissions. Apparently, new security policies in OS X 10.10 don't allow the launchd service (the part of OS X that keeps background processes running, among other things) to start a background agent process if the path to that agent executable passes through a symbolic link that's on a volume that doesn't enforce ownership and permissions.

I know, right?

Enabling ownership for the home folder volume fixed the problem?and is probably a good idea anyway. I'll add some code so that future versions of QRecall will warn unsuspecting users about this situation.