Catalina and Applescript

[danallen]

I have Applescript which executes bash shell script using administrator privileges.

Script example: do shell script "/users/user/documents/install.sh" with administrator privileges

In Catalina, i always get an execution error - operation not permitted (126) message - bash script is not executed. Even if bash script is empty, error is the same, so i assume bash script is not the problem. Tried to do it as root - no success.

If i remove with administrator privileges, script is executed, but that's not a solution because i need to run it with privileges.

In previous macOS versions the same script is working without problems.

Any ideas? Thx in advance!!!

I have bash scripts running on Catalina beta 6. However, there is a narrow condition where I am stuck on the "operation not permitted" Scripts fail that under the following conditions:

Condition 1: The script tries to access a file on a pcie ahci ssd (SAMSUNG MZHPU512HCGL)
Condition 2: The bash script is invoked by cron.
Condition 3: Catalina

The same script invoked from the bash shell command line works fine.

I suspect the problem is cron runs jobs with a zsh shell, and there is something I need to do about this.

 

[zabukowski]

Beta 9 - still the same isue

 

[tongcc8]

I got the same problem with automator app running everytime I login to add some routing. After upgraded, app broken.

 

[zabukowski]

I got the same problem with automator app running everytime I login to add some routing. After upgraded, app broken.

Yes, it's just outrageous, that they didn't fix this for the final release

 

[jcook1975]

Maybe this will help someone out. Been fighting this from a slightly different angle and it seems that paths get bunged up somehow. Was trying to write a do shell that calls install and install would complain about the package path. Changed it to do shell call a .sh script and then got the operation not permitted. Stuck the installer package in /tmp and it worked. Tried with the .sh script (with the script in /tmp) and it worked as well.
To be clear
do shell script "sudo installer -pkg /tmp/some.pkg -target /" with administrator privileges
worked
while
do shell script "sudo installer -pkg /Users/someuser/somedir/some.pkg -target /" with administrator privileges
did not. It threw an error that the package path was invalid although the same installer command runs from the terminal just fine.
Further
If I put the installer command in a shell script
do shell script "sudo /Users/someuser/somedir/script.sh" with administrator privileges
fails with operation not permitted
but
do shell script "sudo /tmp/script.sh" with administrator privileges
worked just fine

So, shoved that .sh in /opt and call works just fine as well.

So at least gives some options where folks might get this to work.

 

[adrianlondon]

I don't have your issue, but a different one. An Applescript I have that sets calendar alerts depending on various bits of into in the event was working fine in Mojave, but is failing now. My Feedback says "more than 10" people have reported the same issue, so there does seem to be at least one issue with Applescript in Catalina.

I've found the error and hence the workaround. Apple have ignored everyone's Feedback requests.

"make new display alarm" generates a meaningless error. It's also listed as a valid option in the script dictionary (that Apple never seem to update, making it more and more useless). However, display alarms have been silently (hah!) removed from the Calendar app, and no longer work.

There's also an issue with Applescripts against the Mail app. The account boolean "account where enabled is true", also listed in the dictionary, also gives a meaningless error. Like the display alarms, it's been silently removed as an option.

Applescript gets dumber and dumber each time a new version of MacOS gets released.

 

[nineup]

A late reply, I'm using MacOS Big Sur now and facing same problem on Automator Applescript with admin privilege.

My workaround is using native sudoers file.
Grant sudo NOPASSWD right on the script location.
do shell script "sudo /xxx/script.sh"

I know it's not a good workaround but at least it works.