2

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? – John Keates Feb 19 at 3:36
  • /usr/lib/cron points to /var/at, so I guess cron uses at. – Joao Encarnacao Feb 20 at 0:07
  • Ah, that makes more sense – John Keates Feb 20 at 3:07
5

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
2

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
0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.