Skip to main content

I have a script which does a dscl lookup on the users home directory, creates a new folder, then populates a desktop alias that directs to this new folder. If I run the script manually, it functions as expected. When run via Self Service or policy, the folder is not created and essentially the script fails. If I set the script to run Once Per User, the script does not execute via policy trigger, and does not display in Self Service. If I set the policy to once per computer, the policy executes but the script does not function as expected. Here is the code, although i think it has to do with the way in which the JSS is handling the script.... Any help / thoughts would be appreciated:



--Set some values for reuse
set theUser to do shell script "whoami" --return lower case values
set theUserPath to do shell script "whoami | tr '[a-z]' '[A-Z]'"
set theFilePath to "/Volumes/" & theUserPath & "$/User_Profile/SanBox" as Unicode text
set serverAddress to do shell script "dscl . -read /Users/" & theUser & " SMBHome | awk '{print $2}' | tr '' '/'"



--display dialog theFilePath



tell application "Finder"



mount volume "smb:" & serverAddress



delay 2



do shell script "mkdir -p " & theFilePath



delay 2



set theFile to POSIX file theFilePath as text
set theAlias to make new alias file at POSIX file ("/Users/" & theUser & "/Desktop") to theFile
set the name of theAlias to "SanBox (Online)"



end tell

I suspect it is not working through Self Service because it is trying to run as root user and not the actual person logged in (console user)



Generally Applescripts are for gui. It is possible to get applescripts written out in a shell script, but its a bit clunky and a bit of a bodge job.



I would consider either




  1. Have a applescript but make it as an application (keeping an editable version for backup) which is set as a login item.


  2. Same as 1 but instead of setting it as a logged in item, have a shell script to open the application as the current console user and chuck it in Self Service.


  3. Forget applescript and look at a shell script which would run in self service.




When I had a similar dilema I chose option 2 because I already had the applescript syntax working in my test environment and didn't see any point tearing my hair out any further.

Its late and slow at work. here is a skeleton JS:



#!/bin/bash
NAME=whoami
finger $NAME | mkdir /Users/$NAME/Desktop/Home



sleep 2



ln -s /Users/$NAME/* /Users/$NAME/Desktop/Home/



it is possible to do it in fewer lines, but this way you can see what's going on. please feel free to confirm/correct this if wrong..



Larry

tkimpton is right. Whenever a script runs through Casper., regardless if if its being done by an every15 trigger, run through Self Service or whatnot, it runs as root, or more accurately,as the service account that manages your Macs escalated to root privs.
For Self Service, you could get the logged in user with the built in $3 variable (same for Login/Logout scripts), but I personally have gotten into the habit of grabbing the user at console with something like-



who | awk '/console/{print $1}'



This makes scripts a little more portable since it will work outside of login/logout/Self Service.



The other thing is, for what you're looking to do, you should look at making it just a shell script. Applescript is best for when you need some interaction with the user, such as input, or displaying a series of messages. Since your script isn't doing that, just make it a shell script. If you need some help with that, many people here are good with shell scripts and can help you put this together.

Thanks All for the assistance. I was able to successfully execute the Applescript using tkimpton's recommendation. I basically created a package that drops the Applescript App into a local directory, then execute a shell script which runs the app. Next time, I'll look to compile a shell script for this type of function.



Thanks again.

Terms & ConditionsCookie settings