tmutil script runs in terminal but doesn't work in a cron job

Question

ric982 Author

Level 1

10 points

tmutil script runs in terminal but doesn't work in a cron job

I've got a korn shell script that issues either one of the following

sudo tmutil enable

sudo tmutil disable

I've updated sudoers.d so that these commands can be issued by my userid without a password.

If I issue the above commands in terminal, they work without password and I can see the Time Machine

Prefrences "Back up Automatically" turn off (when disable) and on (when enable). If I run my wrapper script from terminal, it also works (and additionally logs to a file and checks exit codes and logs any errout from the commands).

Running in cron, I can see from the logs that cron is in fact running the script at the specified times.

The disable command runs without error - but it doesn't change the state of Time Machine. The enable command gets exit code 80 and sends errout indicating I need to add the Terminal app to set of apps with Full Disk Access. I have done that. No change to the results.

I'm running my Time Machine to a NAS box and I want to replicate that data to the cloud. I'm trying to stop/start time machine each day so I can copy that data on the NAS to the cloud while it's not changing. I'd like to schedule this as an automated script that runs each night. The fact that Time Machine's backup start times drift (seems like it backs up every 62 minutes) doesn't help. Perhaps there is some other way to accomplish what I'm trying to do, but if I could figure out how to fix why the cron jobs are failing I think I've got a solution.

Any ideas on how to fix my cron ?

Mac Studio, macOS 12.6

Posted on Oct 17, 2022 5:17 PM

Reply

Answer 1

Top-ranking reply

ric982 Author

Level 1

10 points

Oct 18, 2022 8:28 AM in response to BobHarris

Thanks for the reply Bob.

So here's what fixed the problem:

Needed to give 'cron' full disk access. Then things started working.

I must have already given Terminal full disk access because it was working there. Turning off full disk access on Terminal caused the same failures I was seeing when I ran with cron.

Other things I notice or found out:

1) set -x did not reveal anything I wasn't already seeing via logging.

(Haven't used set -x before - nice to know about that - thanks).

2) I was getting mail from cron for the sudo tmutil enable command which was failing with exit code 80. Actually, I think the mail got created because the exit code 80 was detected in my script which did 'exit 1' as a result.

(Haven't seen mail in terminal before and now know cron will send it - nice to know about that - thanks).

3) sudo tmutil enable - was faiiling with exit code 80 because it didn't have full disk access. The error message text said to give Terminal full disk access (which is needed if you want to run this in terminal). But it is also needed for cron if you want to run it there.

4) sudo tmutil disable - gave exit code 0 and no error message even though it didn't run because it didn't have full disk access. This is a macOS bug I assume.

5) Once 'cron' had full disk access, the scripts running via cron do cause the Time Machine System Preferences check box "Back Up Automatically" to change state as expected (like they do when running them from terminal). The mail file is created in /var/mail/ and the name is your user ID. You can cat the file to read it. If you delete it, Terminal stops indicting "You Have Mail".

6) The reference I found about fixing this also recommended using launchd instead of cron so you don't need to give Full Disk Access to cron or terminal. I haven't bothered to find a reasonable editor for launchd and I'm just going to rely on deprecated cron for now. Reference: https://geekanddad.wordpress.com/2022/02/07/automatic-once-a-day-time-machine-backups/

So, I'm all good on this problem. Thanks again.

Reply

Answer 2

BobHarris

Level 9

57,047 points

Oct 17, 2022 5:50 PM in response to ric982

When you run a script via cron job, the cron environment starts with a very limited environment. Maybe that is affecting how your script works

PWD:    /Users/your_user_name

id -a:  uid=501(your_user_name)
        gid=501(your_user_name)
        groups=501(your_user_name),
               204(_developer),
               100(_lpoperator),
                98(_lpadmin),
                80(admin),
                61(localaccounts),
                12(everyone)

$#:     0  # no command line arguments.

printenv:
        SHELL=/bin/sh
        USER=your_user_name
        PATH=/usr/bin:/bin
        PWD=/Users/your_user_name
        SHLVL=1
        HOME=/Users/your_user_name
        LOGNAME=your_user_name
        _=/usr/bin/printenv

Do you have error messages when it does not work?

Can you run with

set -x

enabled and look at the results.

Generally cron mails the output from the cron job to you and you can read the mail using a utility such as

mailx

see "man mailx"

Reply

Answer 3

BobHarris

Level 9

57,047 points

Oct 18, 2022 11:56 AM in response to ric982

I’m a long time cron user, and creating a plist is too much like writing html with all that <tag this> and <tag that>. Cron is so much simpler 😀

I'm sure I discovered the Full Disk Access for cron sometime in the past, but forgot about is, which is why I didn't mention it. Then again, my current personal Mac and my work Mac did not have cron in Full Disk Access, so it must have been lost when I upgraded systems.

Reply

tmutil script runs in terminal but doesn't work in a cron job

Similar questions