After updating my OSX to Mojave, it seems I am no longer able to edit my crontab. Any attempt to do so results in the error message on the title of this question.

I tracked crontab to /private/var/at and the permissions are the same as another computer running El Capitan:

/private/var/at$ ls -laO
total 0
drwxr-xr-x   8 daemon  wheel  -           256B Feb 18 16:47 ./
drwxr-xr-x  26 root    wheel  sunlnk      832B Feb 18 16:51 ../
-rw-r--r--   1 root    wheel  -             0B Aug 22 22:11 at.deny
-rw-r--r--   1 root    wheel  compressed    6B Aug 17  2018 cron.deny
drwxr-xr-x   2 daemon  wheel  -            64B Aug 17  2018 jobs/
drwxr-xr-x   2 daemon  wheel  -            64B Aug 22 22:11 spool/
drwx------   4 root    wheel  -           128B Nov 22 12:46 tabs/
drwx------   2 root    wheel  -            64B Feb 18 15:04 tmp/

/private/var$ ls -laOd at
drwxr-xr-x  8 daemon  wheel  -  256B Feb 18 16:47 at/

/private$ ls -laOd var
drwxr-xr-x  26 root  wheel  sunlnk  832B Feb 18 16:51 var/

Unlike that computer, any sudo change I try to do below /private/var/at (e.g. sudo touch test) gets "Operation not permitted". On /private/var and above, i am able to sudo change anything (as in the limited and obvious type of changes i tested inside /private/var/at, not anything).

There is something preventing me from changing the contents of /private/var/at and I think this is what is causing the crontab error message because crontab is not able to write to /private/var/at/tmp and create the tmp crontab file that is reported in the error message.

I know crontab is not the preferred method in OSX but that's not the point of this question.

  • Isn’t at for atd and not cron? Feb 19, 2019 at 3:36
  • /usr/lib/cron points to /var/at, so I guess cron uses at. Feb 20, 2019 at 0:07
  • Ah, that makes more sense Feb 20, 2019 at 3:07

4 Answers 4


The short answer:

Go to System Preferences > Security & Privacy and give Full Disk Access to Terminal.

The long answer:

  1. Pull down the Apple menu and choose ‘System Preferences’
  2. Choose “Security & Privacy” control panel
  3. Now select the “Privacy” tab, then from the left-side menu select “Full Disk Access”
  4. Click the lock icon in the lower left corner of the preference panel and authenticate with an admin level login
  5. Now click the [+] plus button to add an application with full disk access
  6. Navigate to the /Applications/Utilities/ folder and choose “Terminal” to grant Terminal with Full Disk Access privileges
  7. Relaunch Terminal, the “Operation not permitted” error messages will be gone
  • Thanks! For those that ssh in to your mac, you may also need to give full access to console.
    – BruceJo
    Mar 6, 2022 at 23:49

I had to add cron to System Preferences > Security & Privacy > Full Disk Access

  1. Find privacy preferences: CMD + Space, "priv"

  1. Unlock preferences for Full Disk Access and open selection menu

  1. In selection menu press CMD + Shift + . to unhide hidden files and navigate to /usr/sbin/cron. (You may check your cron executable location by running $ which cron in terminal)



Another approach without requiring any permission changes, which relies upon the fact that sshd is already enabled for 'Full Disk Access', is to perform the crontab updates via ssh to localhost (provided Remote Login/ssh is enabled in Sharing System preferences) e.g:

ssh localhost
crontab -e

The sandbox is preventing you from writing the crontab. If you run the crontab command…

  • using Terminal on local machine: System Preferences > Security & Privacy and give Full Disk Access to Terminal
  • using a third party terminal app: System Preferences > Security & Privacy and give Full Disk Access to third party terminal app
  • via ssh from another machine: it should work (see @Pierz' answer)
  • from the screen command: either log out of screen or use @Pierz' answer.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .