Crontab Operation not permitted

Question

I have the following crontab on my mac OS Catalina 10.15.1 :

* * * * * /Users/username/Desktop/cronjob.sh > /Users/username/Desktop/cronjob.log 2>&1

Within the command file is:

#!/bin/bash

touch /tmp/foo

However I was left with the following line inside cronjob.log

/bin/bash: /Users/username/Desktop/cronjob.sh: Operation not permitted

---

Why is operation not permitted event though the permissions for cronjob.sh is set to +x?

Answer 1

In your case you have to add cron as "parent" app to the user's Security & Privacy > Privacy > Full Disk Access apps/execs.

Depending where to read the script from and where to write the log file to, you have to add cron to the Full Disk Access apps. Almost all default folders in the user's home are protected (Documents/Downloads/Desktop - I haven't checked Pictures/Movies/Music but I think they are protected too and obviously the wrong folders to add shell scripts or log files) by Catalina's system policy.

If the script and the log reside in user created and thus unprotected folders (e.g. the script in ~/bin and the log file in ~/log) it works without adding cron to the Full Disk Access group.

To add the exception:

1. click the + button
2. hit ⌘⇧G
3. enter /usr/sbin
4. double click the cron file.

---

You can check this kind of errors by opening Console.app and searching for the shebanged exec in the script (here bash):

error   15:19:00.369105+0100    kernel  Sandbox: bash(4556) System Policy: deny(1) file-write-data /Users/user/Desktop/test/cronjob2.log
error   15:19:00.379093+0100    kernel  Sandbox: bash(4555) System Policy: deny(1) file-read-data /Users/user/Desktop/cronjob.sh

In the examples above cron wasn't added to the Full Disk Access group.

cronjob2 was run from an unprotected folder ~/bin but tries to write the log file to the protected folder ~/Desktop/test/. So no read error but a write error.

cronjob was run from a protected folder ~/Desktop and tries to write the log file to the protected folder ~/Desktop/. So a read error.

Interestingly both log files are created - the first one (cronjob2.log) is empty though.