36:149: execution error: An error of type -10810 has occurred. (-10810)

try sudo -u $3 instead of su $3

@bpavlov That doesn't appear to work either. It looks like a syntax issue though

Code:

echo "Attempting to add CCAAgent.app to Login Items for $3 using 'sudo -u'"
sudo -u "$3" -c "osascript -e 'tell application "System Events" to make new login item at end with properties {path:"/Applications/CCAAgent.app", name:"CCAAgent.app", hidden:false}'"
echo "Done"

Output:

Attempting to add CCAAgent.app to Login Items for MYID using 'sudo -u'
usage: sudo -h | -K | -k | -L | -V
usage: sudo -v [-AknS] [-g groupname|#gid] [-p prompt] [-u user name|#uid]
usage: sudo -l[l] [-AknS] [-g groupname|#gid] [-p prompt] [-U user name] [-u
user name|#uid] [-g groupname|#gid] [command]
usage: sudo [-AbEHknPS] [-C fd] [-g groupname|#gid] [-p prompt] [-u user
name|#uid] [-g groupname|#gid] [VAR=value] [-i|-s] []
usage: sudo -e [-AknS] [-C fd] [-g groupname|#gid] [-p prompt] [-u user
name|#uid] file ...
Done

My apologies for not giving you a full response earlier. I've been scripting all day and figured if I gave you a snippet of something I saw that stood out to me that it might get you going. Didn't test anything else. I did test this out though and it works.

sudo -u $3 osascript -e 'tell application "System Events" to make new login item at end with properties {path:"/Applications/iTunes.app", name:"iTunes.app", hidden:false}'

Hope that helps.

Hi @bpavlov No luck with that either, but the syntax error did go away:

Code:

echo "Attempting to add CCAAgent.app to Login Items for $3 using 'sudo -u'"
sudo -u $3 osascript -e 'tell application "System Events" to make new login item at end with properties {path:"/Applications/CCAAgent.app", name:"CCAAgent.app", hidden:false}'
echo "Done"

Output:

Attempting to add CCAAgent.app to Login Items for MYID using 'sudo -u'
36:149: execution error: An error of type -10810 has occurred. (-10810)
Done

I've had to get a bit fancier to get applescripts to execute as the user more consistently:

loggedInUser=$( ls -l /dev/console | awk '{print $3}' )
loggedInPID=$( ps -axj | awk "/^$loggedInUser/ && /Dock.app/ {print $2;exit}" )

/bin/launchctl bsexec "${loggedInPID}" sudo -u "${loggedInUser}" /usr/bin/osascript -e 'tell application "System Events" to make new login item at end with properties {path:"/Applications/iTunes.app", name:"iTunes.app", hidden:false}'

Give it a go and see if it'll work for you.

Hi @cdev I started fresh with your script, but just added some echo's to output. Getting loggedInUser that way never works for some reason on my systems. It always returns root, so i used $3

Code:

#!/bin/sh

loggedInUser=$( ls -l /dev/console | awk '{print $3}' )
loggedInPID=$( ps -axj | awk "/^$3/ && /Dock.app/ {print $2;exit}" )

echo "Logged in user: $loggedInUser"
echo "JAMF logged in user: $3"
echo "Logged in PID: $loggedInPID"

echo "run command"
/bin/launchctl bsexec "${loggedInPID}" sudo -u "${3}" /usr/bin/osascript -e 'tell application "System Events" to make new login item at end with properties {path:"/Applications/iTunes.app", name:"iTunes.app", hidden:false}'
echo "Done"

Output:

Logged in user: root
JAMF logged in user: MYID
Logged in PID: 
run command
sudo: unknown user: MYID
Done

the account for "MYID" is an AD account which is an admin, managed, and mobile on this machine. I'm using the native AD integration. Not sure if that's something different from others where this code is working. No PID seemed to be returned this time either

Weird, I should have probably tested in the JSS and looked at the results on a computer. My advice command definitely failed because I only tested in the command line (which succeeded) and checked the results in the JSS log (which succeeded) but didn't actually look to see if the login item got removed on the computer (which failed). Yesterday was a long day.....mentally exhausting...However @cdev got it right.

Question for @cdev or anyone that can answer this: I read up on bsexec in the launchctl man page but it's not very obvious to me why we would run this command this way. I was under the impression that launchctl was to interact with launchd which launches daemons? While the original poster's issue was resolved, I'm asking just to gain some more insight on when it's appropriate to use this and what's actually happening when using launchctl bsexec.

@Jason Forget running it from the JSS for a second, what happens if you run the script through the command line. Run it like this:
bash -x /path/to/script.sh

That works, but pretty much all of these suggestions work fine if i run it directly.

Code:

#!/bin/sh

loggedInUser=$( ls -l /dev/console | awk '{print $3}' )
loggedInPID=$( ps -axj | awk "/^$loggedInUser/ && /Dock.app/ {print $2;exit}" )

echo "Logged in user: $loggedInUser"
echo "JAMF logged in user: $3"
echo "Logged in PID: $loggedInPID"

echo "run command"
/bin/launchctl bsexec "${loggedInPID}" sudo -u "${loggedInUser}" /usr/bin/osascript -e 'tell application "System Events" to make new login item at end with properties {path:"/Applications/iTunes.app", name:"iTunes.app", hidden:false}'
echo "Done"

Output:

terminal$ sudo bash -x ./Script.sh
Password:
++ ls -l /dev/console
++ awk '{print $3}'
+ loggedInUser=MYID
++ ps -axj
++ awk '/^MYID/ && /Dock.app/ {print $2;exit}'
+ loggedInPID=2305
+ echo 'Logged in user: MYID'
Logged in user: MYID
+ echo 'JAMF logged in user: '
JAMF logged in user: 
+ echo 'Logged in PID: 2305'
Logged in PID: 2305
+ echo 'run command'
run command
+ /bin/launchctl bsexec 2305 sudo -u MYID /usr/bin/osascript -e 'tell application "System Events" to make new login item at end with properties {path:"/Applications/iTunes.app", name:"iTunes.app", hidden:false}'
login item iTunes.app
+ echo Done
Done

It does add to Login Items correctly.

I played around with this type of thing yesterday out of self service. What I finally got working was to copy the script that is actually going to run stuff as the user to the root drive and fix the permissions on the script before trying to execute it as the user. So, I have script A.pl yes I am a perl scripter. that checks to see if the script the user exists on the root drive, if not copy that script from CasperShare/Scripts to /tmp/B.pl, make sure it has read and execute permissions 555 set.
then the bsexec calls the script /tmp/B.pl and it all works.
fyi, you can alternatively run bsexec with su instead of

launchctl bsexec PID su USERID -c '/tmp/B.pl'

As I understand it, the reason for running bsexec is because it then runs within the specified user's active session, including security rights and exceptions. Yes, the command is being run via su/sudo, but since it behaves as though the local user ran it, it behaves as intended. With all of the sandboxing and security rules that are being added to OS X (especially Yosemite), this even more important since even su/sudo won't break outside of the segmentation of processes and file access for certain tasks. AppleScript is especially sensitive to this since it was only designed to run within the user space (high-level access), not as a shell or other low-level access tool.

@nessts more bad luck. Seems like su doesn't see that my account exists. But if i run it directly it works just fine

Script at /tmp/localScript.sh:

#!/bin/sh

echo "run command in script"
/usr/bin/osascript -e 'tell application "System Events" to make new login item at end with properties {path:"/Applications/iTunes.app", name:"iTunes.app", hidden:false}'
echo "Done with script"

Script from policy:

#!/bin/sh

loggedInUser=$( ls -l /dev/console | awk '{print $3}' )
loggedInPID=$( ps -axj | awk "/^$3/ && /Dock.app/ {print $2;exit}" )

echo "Logged in user: $loggedInUser"
echo "JAMF logged in user: $3"
echo "Logged in PID: $loggedInPID"

echo "run command"
/bin/launchctl bsexec "${loggedInPID}" su "${3}" -c '/tmp/localScript.sh'
echo "Done"

Output:

Logged in user: root
JAMF logged in user: MYID
Logged in PID: 
run command
su: unknown login: MYID
Done

$3 doesn't work in a regular policy. only either from Self Service or login (maybe logout too), but regular policy runs will not understand what $3 is. I haven't read through all this, so sorry if you already tried, but have you tried getting the logged in username with something like ls -l /dev/console | awk '{print $3}' and then using that in the above commands?

@mm2270 the /dev/console line doesn't seem to work for me. When I run it at login and review the output it returns "root" instead of my user ID that i'm actually logged in with. $3 is appearing to return my user ID and the "su: unknown login: MYID" line seems to indicate that it's attempting to run with the correct ID, just not succeeding.

Ah, sorry, didn't see that you're doing all this at login, so yes, $3 should get the logged in user. Also, I've read (not experienced) that Yosemite introduced some issues with using the /dev/console line to get the logged in user at login time. Seems there is some kind of timing issue at play where the console still thinks its at the login screen (therefore owned by root) when the script runs. That always used to work OK pre-10.10, so something changed that's affecting that.

Honestly, the launchctl bsexec stuff should be working for you though. I've not seen that fail for me, except on occasion. Generally it always works to run the command as the user, so that's kind of odd its not working for you.

@mm2270 it's good to at least know that others have seen it work in Yosemite, so there is some hope. Just curious since nobody has explicitly stated, is there any issue with launchctl bsexec working with AD accounts at logon? I do know the account i'm testing with wouldn't be listed in the /etc/passwd, but i'm not sure if that's what su is looking at when it's saying "Unknown account". I'm going to try an add a sleep to the script to see if that helps any.

When I tested it out on my computer, I pushed it out via Casper Remote while I was logged in under my AD account. Does it work under that condition? I am running on 10.9.5 though....

@Jason We use launchctl bsexec all the time with AD accounts. We are pretty much all AD cached mobile accounts here. However, we rarely ever do anything at login. Our users log out so infrequently that it doesn't make sense for us to deploy things on that trigger. So I can't say for sure if there is some issue with that running at login under Yosemite, but its possible I guess.

Similar, but using Python:

#!/usr/bin/python
import sys,pwd,os
import subprocess
from os import system

u = os.getlogin()
if ( u == '_atsserver') or ( u == 'root'):
    print "no login items for root."
else:
    print "Adding login item..."
    pw = pwd.getpwnam(u)
    os.initgroups(u,pw.pw_gid)
    env={"TERM":"xterm","USER":pw.pw_name,"HOME":pw.pw_dir,"SHELL":pw.pw_shell,"LOGNAME":pw.pw_name,"PATH":"/usr/bin:/bin:/opt/bin"};
    os.setgid(pw.pw_gid);
    os.setuid(pw.pw_uid);
    os.execve('/usr/bin/osascript',["", "-e", 'tell application "System Events" to make new login item at end with properties {path:"/Applications/iTunes.app", name:"iTunes.app", hidden:false}'],env);

@jacob_salmela This appears to work just fine from terminal, but oddly enough it's not even trying to run at login. It's just showing pending. I can run it manually with "sudo jamf policy -id <POLICYID>" and it works though. Here are screens of how the policy is setup:

@Jason It works fine here and I set up my test policy exactly the same way. We use local users and are running 10.9 machines on JSS 9.72.