Root doesn't have permission on User home folders

[kacey3]

I have a script that used to work that cleans up some common home folders on an auto-login account, but recently I have discovered that it no longer works. The script is very simple and I see no reason why it wouldn't work:

# Fetch the target user if desired, otherwise use the currently logged in user.
if [ "$4" != "" ]; then
    TargetUser=$4
else
    TargetUser=$3
fi
echo "Target user is $TargetUser."

# Delete common user spaces of the targetted user.
rm -Rf /Users/$TargetUser/Desktop/*
rm -Rf /Users/$TargetUser/Documents/*
rm -Rf /Users/$TargetUser/Downloads/*
rm -Rf /Users/$TargetUser/Applications/*
rm -Rf /Users/$TargetUser/.Trash/*

exit 0

The problems is the script doesn't actually do anything. The policy runs as scheduled, and reports no errors, but nothing is actually deleted from any of the designated spaces. The logs report back that the correct user was targeted, the policy runs at Checkin, so the computer is fully up and logged in, but nothing is deleted, as if the script does not have rights to the target user's folder. I've always understood that Jamf ran all scripts as root and thus should have access to delete any files in these locations.

Furthermore, if I run the policy by actually running "sudo jamf policy -event {event trigger} from the computer locally, it actually works just fine, it's only when it runs as a result of the policy that it fails. I'm very confused by this. My computers are running MacOS 10.15.7 on the client and Jamf Pro 10.35.

[mm2270]

$3 does not always get populated as the currently logged in user, which is where the issue may be. I say "may" because I don't know for certain. It's just a guess.

You can try getting the logged in user in the script rather than relying on the jamf binary to know what the logged in user account is. For example:

TargetUser=$(/usr/sbin/scutil <<< "show State:/Users/ConsoleUser" | awk '/Name : / && ! /loginwindow/ {print $3}')

See if that helps any.

Edit: Looking back at your post again, I missed where you said this:

---

@kacey3 wrote:

Furthermore, if I run the policy by actually running "sudo jamf policy -event {event trigger} from the computer locally, it actually works just fine, it's only when it runs as a result of the policy that it fails.

---

I'm nearly certain that is the reason. $3 gets populated with Self Service and manually called policies, but typically doesn't with a policy called by the recurring check-in trigger.

[kacey3]

I can try that, but I have confirmed that $3 is actually reporting the correct user, per the line in the script:

echo "Target user is $TargetUser."

I mean, at this point, I'll try most anything, but I definitely ruled that out early on.

[mm2270]

Hmm, well, that's odd. If it's getting the correct username, it should be able to make any changes to those paths, since, as you said, it's running as root.

Maybe add an extra couple of lines into the script to confirm it can see the path. For example, something like:

if [ -d "/Users/$TargetUser/Desktop" ]; then
     echo "/Users/$TargetUser/Desktop path exists"
     rm -R "/Users/$TargetUser/Desktop/*"
else
     echo "/Users/$TargetUser/Desktop could not be found"
fi

I'll be curious to see what it reports.

[kacey3]

Script result: Target user is cvadsharedstu.
/Users/cvadsharedstu/Desktop path exists
Successfully cleared cvadsharedstu home folders.

 And yet, still nothing was deleted from the desktop. I'm very confused by this. If it would at least throw an error that would be something.

[Fluffy]

Validated for sanity. I was able to replicate it* without using a variable. The script is able to detect the file, but does not delete it and does not throw any errors.

*Using Scripting Module in Jamf School.

[kacey3]

Well, if nothing else, it's nice to know that I'm not going crazy!

It's super frustrating though because it had definitely worked in the past but when I went to check our computers for the new semester (starting Tuesday), I discovered that all of them were cluttered with student files.

Nothing like assuming something's been working for months, only to discover it's not been working at all!

[Fluffy]

Was able to produce an error code. I am using a single file to run these tests, but I would hope that wouldn't make a difference. Using @mm2270's recommended line to detect the user and added exits. Adding the exit 1 finally produced an error message.

#!/bin/sh

TargetUser=$(/usr/sbin/scutil <<< "show State:/Users/ConsoleUser" | awk '/Name : / && ! /loginwindow/ {print $3}')

if [[ -e /Users/$TargetUser/Documents/remove.txt ]]; then
	echo "File exists."
else
	echo "File doesn't exist."
fi

rm -Rf /Users/$TargetUser/Documents/remove.txt

if [[ -e /Users/$TargetUser/Documents/remove.txt ]]; then
	echo "File exists."
	exit 1
else
	echo "File doesn't exist."
	exit 0
fi

Error (user edited):

1:233: execution error: rm: /Users/user/Documents/remove.txt: Operation not permitted (1)

I'm still green, so this may be a fluke or an error from something else. Hopefully this helps somehow.

An alternative may be to make a launchagent/daemon to run the script locally. I made a launchagent using this post (with some tweaks) to logout users as well as deleting the Guest user folder, which does indeed delete the folder/files.

[kacey3]

I was fairly certain it was an incredulous permission error (root should have permission to do virtually anything, so deleting a standard user file should be well within the realm of root's rights).

I've considered making it a LauchAgent, but I have some logistical and philosophical issues with that.

1. We are paying for Jamf to be our automated/remote management solution, so why do I have to write LaunghAgents to do the things that should be able to be handled by Jamf, by design.
2. We have different classrooms with different schedules, which means writing a different LaunchAgent for each area rather than one script that targets all computers, triggered by different policies with different recurring schedules.

It really seems like there is some kind of error in the Jamf system that would result in this failure, especially if it works by running the same policy manually. It's only when it's run by a trigger that it fails.

[kacey3]

Nevertheless, your testing has proven something I was fairly certain of, and I appreciate the confirmation!

[kacey3]

I've been working with Jamf Support on this for the past month and their ultimate answer was "there must be something wrong with your script, we recommend getting professional assistance with your script writing."

😳

[arnokenis]

Hi @kacey3 

Did you ever get a resolution to this issue?
I created a simple script to delete a cache folder in a user directory and I get the same error as you are getting.

Script result: rm: /Users/akimpj0/Library/Application Support/Microsoft/Teams: Permission denied

[kacey3]

I  have not. I believe the issue is on the Jamf end, but I don't know how to fix it or work around it. They have accepted that it is an issue, but I don't know if they have accepted that it is their issue to fix. They spent more time trying to help me rewrite my script than actually addressing the root of the problem.