OSX needs to repair your Library to run appliations - Mojave 10.14 Madness

andyfreeman
New Contributor

Having a weird issue with Mojave laptops after enrolling them onto Jamf

Enroll + Bind to AD - The AD user then logs in as normal

It logs in straight away to the desktop, without going through the usual "login with your apple id, register your fingerprint, turn on siri etc" process, and then presents them with an enternal "OS X needs to repair your Library to run applications" loop.

It seems to be a permissions issue, and only on Mojave machines - I enrolled a High Sierra machine yesterday and didn't have this problem.

As a temporary shitfix I logged in as administrator, installed Cleanmymac (as I know it has a fix permissions feature, which OSX no longer seems to have these days), log back in as the AD user, run the fix permissions, log out, and finally log back in again as the AD user. At this point I am greeted by the normal "new user" process that they should have been greeted with the first time.

Does anyone have any idea what the hell might be going on here? I have no idea where to even start!

5 REPLIES 5

sshort
Valued Contributor

Apple still allows you to repair home folder permissions.

Others have reported that issue if you're editing the User Template folder in Mojave.

kstrick
Contributor III

I hade some issues with this, i had to re-evaluate any changes i made to the user templates-- don't even think of touching the 'Safari' folder.

nkuhl30
Contributor

kstrick, were you able to successfully modify the user template? If so, and other than the Safari folder, what did you not modify to get it to work?

andyfreeman
New Contributor

Weirdly, that I am aware of we don't edit user templates at all - How would you all go about narrowing down where this is coming from?

MTFIDjamf
Contributor II

We were seeing this when some devices were misconfigured after their AD bind.

In the Search Policy> Search Paths, we set custom search paths. By default, the /AllDomains search path was created; we need to delete this due to AD issues in the past. Our script was not always deleting this during the bind. With /AllDomains still present every first user logon went crazy with this issue.

Once the /AllDomains search path was removed, the first time login for the users no longer had any of these issues.