Im new to jamf, so bear with me. I have a script that runs just fine if the user is logged in as Root, but not as an admin. The script is removing an old asset management client. What ive found, is the rights on Waiting Room is limiting the script from running successfully. If there a way to grant everyone access to the Waiting Room folder?
+24The Waiting Room permissions are set to root only on purpose by Jamf. I don't know the specific reason why, but my guess is since it's a caching location, Jamf probably figured it would be best to limit access to this folder from prying eyes so users cannot grab items from it to store for later or delete them if they are trying to bypass a policy that will run later, for example.
That being said, I would not mess with the permissions on it. It might be fine to do it, but I would probably leave it alone personally.
Any scripts that run from a Jamf Pro policy run with root privileges and should have no problem with, say, removing the contents or reading the contents of the Waiting Room folder. It will not be able to show the contents in the Finder to someone however, since the root privs only apply in the shell when the script is running.
Maybe you can elaborate on what you need to do that would require a regular non root account having access to that folder. Maybe there's a better approach you can take if you help us understand the need.
+3I just found a work around, but for my own understanding ill elaborate. We are removing an agent from a program called BMC Asset Core. The removal script is a txt file from BMC. I packaged the txt file into a DMG and am deploying the DMG to the targeted computers, and using a script to open the DMG, and sudo the txt file. From there the agent removes itself from the MacBook. Im assuming the issue is in the "open file.dmg" stage.
For now Im able to cache the dmg on the MacBooks, then use JAMF Remote to deploy the script.
+24OK, but, you really shouldn't need to do any of that. As I mentioned, scripts added to a policy in Jamf Pro run as root. You should simply be able to run the script in a policy and not need to package it, deploy it, open the dmg, run the script, etc etc. Unless I'm overlooking something that seems like a lot of unnecessary steps.
+3Odd. When I attach the script to the policy, it fails saying that the dmg does not exist. Yet when I deploy the same exact script through Jamf Remote, it works.
+24What DMG? I guess what I'm saying is, you may be able to take the script file provided by the vendor (where you said "The removal script is a txt file from BMC.") and just use that as is in a policy.
Add the script as a new script file to your Jamf Pro environment. Then create a new policy and add that script under the Scripts payload and then scope that to a test machine to see if it works. My guess is if it works from Jamf Remote, it should work in a regular policy too.
But to back up a moment, what is in the Waiting Room folder exactly that you need to try to remove? Or was Waiting Room just a location where you were caching the DMG that contained the script you were trying to run?
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.