I’ve been using the following command in an AppleScript which sends me a push alert if a backup hasn’t been done within a set number of days. It has been working without issue up until upgrading to Mojave and now it throws the following error. I have already tried adding tmutil and terminal to ful disk access in the privacy settings, however the error persists…
set tmLatest to do shell script “/usr/bin/tmutil latestbackup”
“The operation could not be completed because tmutil could not access
private application data on the backup disk. Use the Privacy tab
in the Security and Privacy preference pane to add Terminal to the
list of applications which can access Application Data.”
If you reread my post you will see that I’ve already done exactly that and I still get the same result which by the way is reported as an error in the script output. I’m aware of the enhanced security measures employed by Mojave, however this issue seems to run deeper. Perhaps because I’m calling a shell script, I need to add a helper application to full disk access?
I’ve no idea what’s causing the problem, but some thoughts are:
Why are you getting a message about Terminal when you’re using do shell script?
tmutil’s manual says that several of its verbs require root privleges. Is latestbackup one of those? If so, you may need to use do shell script’s administrator privileges, user name, and password parameters.
How is the script being run? If as a compiled script, the application running it will need to be granted the relevant access. If as an application in its own right, that application will need to be granted access. If as an application, and it uses persistent variables (properties, globals, or variables used in the run handler without being declared local), the saving of these variables back to the script file after each run could be causing changes which make the security system suspicious next time round.
Not related to the problem, but could you please use this forum’s [applescript] and [/applescript] tags when posting Applescript code here? There’s a button for them just above the “Message” field on posting pages. Cheers.
it also didn’t worked for me… initially .
I then added the Terminal to “Accessibility” of “Security and Privacy” system preferences.
Same error.
I then also added the Terminal to “Full Disk access” of “Security and Privacy” system preferences.
And now it is ok if I call it from the Terminal or from SD using:
set tmLatest to do shell script "/usr/bin/tmutil latestbackup"
As well as Yvan’s suggestion, this sort of thing is often the result of a script crashing during a previous run and leaving the file open with write permission. If that’s the case here, the easiest cure is to quit Script Debugger (or whatever’s running the script) to close all its open file accesses and relaunch it. When using ‘open for access’, everything thing that happens while the file’s open should be in a ‘try’ statement so that, if there’s an error, the script keeps going long enough to close the file:
set openFile to open for access file targetFile with write permission
try
-- Your stuff here.
close access openFile
on error errMsg
close access openFile
display dialog errMsg
end
Nigel. Should the first line of your script be within the try statement? Otherwise, if the file is already open, the script throws an error and doesn’t close the file.
I work on the theory that once a script’s been prevented from causing this problem, it’s never going to need to fix it.
Open-file access channels belong to the application running the script and only one application can have write-permission access to a particular file at any one time. An application’s access channels are closed either when it (or a script it’s running) closes them explicitly or when it quits and the channels are closed automatically.
So if you run into a problem where a script can’t open a file that’s already open with write permission, it’s either because the script’s running in an application which, since it was launched, has run a faulty script which left the channel open — in which case the problem script needs to be fixed — or because some other application already has write-permission access to the file — in which case the current application won’t be able to close the write-permission channel anyway.
You could, if you deemed it necessary, put the ‘open for access’ command in its own ‘try’ statement to trap occasions when another application already had write-permission access to the file, or when the specified location didn’t exist or was otherwise protected. This would prevent the current script from erroring out and allow it time to perform any tidying up it needed to do itself.
It wouldn’t be any good putting the ‘open for access’ line in the same ‘try’ statement as the other commands, because there’d just be another error when the script tried to close the channel that hadn’t been opened. You could use a file specifier instead of the access reference in the ‘on error’ section, but there’d still be an error if another application owned the write-permission access causing the problem and you couldn’t be absolutely sure which channel was being closed if the current application had more than one channel open to the file at the time — which is possible.
It can be a bit of a minefield and different people have different philosophies for dealing with it. I personally don’t mind if a script errors when trying to open a file for access because then I can fix the problem causing it. But once a file is open for access, my scripts — and anyone else’s I use — have to take full responsibility for ensuring that any channels opened are closed after use.
