Fixing cron jobs in Mojave

macOS Mojave introduces a new access control mechanism that lets you decide which apps should have access to the calendar database, the user’s contacts, the camera and microphone and even access to the whole drive.

That’s great! (except it breaks some things)

The problem

Those familiar with UNIX-like systems may know about cron, a tiny, well-designed job scheduler that’s installed in all macOS systems and most Linux distributions.

Cron lets you set time-based rules for job execution, so that you can automate things like backups, health checks, setting safe file permissions, etc.

With the introduction of Mojave’s access control mechanism, cron jobs can no longer access certain directories because they hold sensitive data, but what happens when our cron job works with that data?

My script

I have a script, called, that grabs all my files, dotfiles, Calendar database and database, tars them together, encrypts the tarball and pushes the backup to my NAS at home.

I schedule it to run hourly, so once I get home, it pushes the day’s backups to the NAS, great! needs to access certain subdirectories of ~/Library in order to grab the Calendar and Things database, but Mojave doesn’t let it anymore.

The fix

Mojave let’s you add apps and binaries to the “Full Disk Access” whitelist, so let’s see which binary runs my cron jobs:

$ ps aux | grep cron
root            201  0.0  0.0  4295936  1188  ??  Ss  11:50PM  0:00.31 /usr/sbin/cron

Here we see that the binary that runs the system’s cron jobs is /usr/sbin/cron.

Granting Full Disk Access to cron

  1. Go to System Preferences > Security & Privacy > Privacy > Full Disk Access:

  2. Click on the (+) icon to add an item to the list

  3. Press Command+Shift+G to open the Go to Folder… dialog, type /usr/sbin and press Enter:

  4. Look for the cron file, select it and click Open:

That’s it! Now my script can access my user’s ~/Library folder and all it’s contents!

Warning: this is not a great idea security-wise, if a malicious actor can create cron jobs or edit the scripts ran as cron jobs, he or she would have Full Disk Access too. Monitor the system’s installed cron jobs manually or with a tool such as KnockKnock and proceed with caution.