“macOS needs to repair your Library to run applications.” in Mojave

[RedWings]

Question: Is anyone else running into this issue with Mojave? “macOS needs to repair your Library to run applications.” We get this with every new users added when we upgrade to Mojave from previous OSs.

[RedWings]

I was told on another site that if we are using FUT/FEU with DMGs on Mojave, it’s time to stop. Is this true?

[UbiquitousChris]

This is somewhat true. Starting in Mojave, parts of a users home folder are now governed by System Integrity protection, including things like Safari settings, and mail, contacts, and calendar databases to list a few. While these rules don't apply to the user template (meaning you can add these items to the user template), they can't be applied to a users home folder, even if the system is creating an account from the user template.

If you're seeing what I saw during the betas, what happens is if you have an item governed by SIP in your user template, when the Mac goes to create the account, the process that copies the user template to the new account fails, leaving a partially created home folder that's owned by the root user.

When you receive that popup on login, it's likely because the user account doesn't have permissions to access its Library folder since the failed process leaves the owner set to root.

Ultimately, it's probably time to move away from using the user template where possible (easier said than done, especially if you work in Academia). You can still do it, but you have to be very careful about the items you add.

[RedWings]

@UbiquitousChris understood. This is horrible news for us when it comes to packaging. Most of our packages are created using Composer to minimize user interaction with installs and setting User preferences.

[hkabik]

It's a bit more overhead up front, but you could script preference changes with defaults or plistbuddy into an installer .pkg. Certainly not as easy as just grabbing the plist file in composer though.

[allanp81]

Is there a list anywhere of what is now protected in Mojave that used to be ok?

[al786]

I just had this problem with Firefox and Chrome with the FUT/FUE .DMG files. We're not using .PKG installers for everything and the problem has stopped. We just need to find a way to set the Homepages without .DMGs

[UbiquitousChris]

An initial look shows these as being SIP protected in the home folder:

/Users/<username>/Library/Application Support/MobileSync
/Users/<username>/Library/Application Support/CallHistoryTransactions
/Users/<username>/Library/Application Support/com.apple.TCC
/Users/<username>/Library/Application Support/CallHistoryDB
/Users/<username>/Library/IdentityServices
/Users/<username>/Library/Preferences/com.apple.homed.*
/Users/<username>/Library/Preferences/com.apple.mail-shared.plist
/Users/<username>/Library/Preferences/com.apple.universalaccess.plist
/Users/<username>/Library/Messages
/Users/<username>/Library/HomeKit
/Users/<username>/Library/Mail
/Users/<username>/Library/Safari
/Users/<username>/Library/Suggestions
/Users/<username>/Library/Containers/com.apple.VoiceMemos
/Users/<username>/Library/Containers/com.apple.Home
/Users/<username>/Library/Containers/com.apple.Safari
/Users/<username>/Library/Containers/com.apple.iChat
/Users/<username>/Library/Containers/com.apple.mail
/Users/<username>/Library/Containers/com.apple.news
/Users/<username>/Library/Containers/com.apple.stocks
/Users/<username>/Library/PersonalizationPortrait
/Users/<username>/Library/Metadata/CoreSpotlight
/Users/<username>/Library/Metadata/com.apple.IntelligentSuggestions
/Users/<username>/Library/Cookies
/Users/<username>/Library/Caches/com.apple.safaridavclient
/Users/<username>/Library/Caches/com.apple.HomeKit.configurations
/Users/<username>/Library/Caches/CloudKit/com.apple.Safari
/Users/<username>/Library/Caches/com.apple.Safari
/Users/<username>/Library/Caches/com.apple.homed

[RedWings]

@UbiquitousChris This makes sense as we use FUT/FEU for Chrome/Firefox and all our browser plugins. These custom DMGs must be causing the issue. We create these for not only loading custom user prefs, but all so users do not get the "This Application was downloaded...." first time launch popup.

[allanp81]

@UbiquitousChris A quick look through your list suggests that we wouldn't run into any issues dumping stuff into the user template.

Out of interest, how did you compile that list?

[jhuls]

Something apparently isn't connecting in my head.

In reading these explanations I'm interpreting this as only those folders are off limits to using FUT/FEU. If I'm understanding that this is the case, why am I reading that some are blaming Google Chrome and Firefox items as being victims to this as I'm not seeing anything above that is related to them? Those settings reside in Application Support if I recall correctly.

I can certainly script this stuff to install differently but really don't want to if I don't have to.

We deliver custom Chrome and Firefox settings to some of our labs but have only now just updated to High Sierra. We also install a number of Adobe CC application settings into the user template for accounts to get upon logging in for the first time. Testing for Mojave won't be for a few months but it'd be nice to get an answer on this now from those going through the growing pains.

[allanp81]

As far as I can tell, based on how I'm reading it, you will only have issues if you were distribute anything into the directories listed above. Anything going to ~/Library/Preferences (apart from those files listed above) within the /System/Library/User Template should work fine.

[UbiquitousChris]

@allanp81 while I haven't been able to find an official list, I was able to compile this one by attempting to perform an action on my own home directory with root privileges.

In Terminal, I ran the following command (If you're going to do this, do it on a test machine or throwaway account):

sudo chown -R UbiquitousChris ~

This command will attempt to change the ownership of all files located in your home directory to yourself. Even through the command is running as root and I already own the files, the items listed above returned an "operation not permitted" error.

To further verify this, I then ran the following:

touch /Users/UbiquitousChris/Library/Cookies/test.txt
touch: /Users/UbiquitousChris/Library/Cookies/test.txt: Operation not permitted

This command just attempts to create an empty file in the specified directory. Again, despite the fact that I am the owner of the Cookies directory, I get back an Operation Not Permitted.

@jhuls, @allenp81 is correct here. When I was updating our build process to support Mojave, I ran across this issue because we were sticking things in ~/Library/Safari/ as part of our user template. Once I removed that from our template package, home folder creation started working properly.

At some point during the WWDC keynote while talking about Mojave, they casually mention this change. Right around the 1:51:55 mark https://youtu.be/UThGcWBIMpU?t=6715

[jhuls]

@UbiquitousChris Safari makes sense since it was listed above. I was referring to those mentioning above that they had trouble with Google Chrome and Firefox.

[UbiquitousChris]

@jhuls Ah, that I can't personally speak to as we're not deploying custom settings for those apps in our environment. 😊

[UbiquitousChris]

@hkabik This is what I've started doing in our environment. I love it! I find it easier to maintain and it just feels cleaner.

[RedWings]

@jhuls I know none of our custom DMGs install in any of these locations:
/Users/<username>/Library/Application Support/MobileSync
/Users/<username>/Library/Application Support/CallHistoryTransactions
/Users/<username>/Library/Application Support/com.apple.TCC
/Users/<username>/Library/Application Support/CallHistoryDB
/Users/<username>/Library/IdentityServices
/Users/<username>/Library/Preferences/com.apple.homed.*
/Users/<username>/Library/Preferences/com.apple.mail-shared.plist
/Users/<username>/Library/Preferences/com.apple.universalaccess.plist
/Users/<username>/Library/Messages
/Users/<username>/Library/HomeKit
/Users/<username>/Library/Mail
/Users/<username>/Library/Safari
/Users/<username>/Library/Suggestions
/Users/<username>/Library/Containers/com.apple.VoiceMemos
/Users/<username>/Library/Containers/com.apple.Home
/Users/<username>/Library/Containers/com.apple.Safari
/Users/<username>/Library/Containers/com.apple.iChat
/Users/<username>/Library/Containers/com.apple.mail
/Users/<username>/Library/Containers/com.apple.news
/Users/<username>/Library/Containers/com.apple.stocks
/Users/<username>/Library/PersonalizationPortrait
/Users/<username>/Library/Metadata/CoreSpotlight
/Users/<username>/Library/Metadata/com.apple.IntelligentSuggestions
/Users/<username>/Library/Cookies
/Users/<username>/Library/Caches/com.apple.safaridavclient
/Users/<username>/Library/Caches/com.apple.HomeKit.configurations
/Users/<username>/Library/Caches/CloudKit/com.apple.Safari
/Users/<username>/Library/Caches/com.apple.Safari
/Users/<username>/Library/Caches/com.apple.homed

And we get the issue.

[MTFIDjamf]

We do not use any FUT/FEU configurations here at all but were seeing the issue.

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.

[itupshot]

We are seeing this issue now as we are finally getting new computers that come with Mojave pre-installed. We have removed the "offending" folders (Safari, Google, Firefox), and we've also removed the "Dock" folder that we usually also load into the UT (it has our default desktop background setting). The only things we've left in the UT are the plist files in Preferences folder.

We are still seeing the issue after we removed the above. Do we need to reboot the computer after we remove these folders? Or do you think one of the plist files may be the problem? We're trying to go by process of elimination. One of them is a Safari.plist file. Any ideas?

We don't use Config Profiles for these settings because there is no "Once" key. We don't want to force users to have a static Dock or other settings. We just want them to have initial settings that they can then modify.

Another thing we're noticing is that we can Screen Share to the computer, but we can't take control. Is this another SIP trick. This is really annoying. Why isn't there a list somewhere of all these changes?

[PaulHazelden]

@itupshot The Screen share but not control is Apple. Apparently if it is pushed out by MDM, you can set it and it will work. Not entirely sure if it has to be DEP as well to work.

[itupshot]

@PaulHazelden It's a script that we run from JamfPro:

#!/bin/bash

## Set Remote Login (SSH) ON
systemsetup -setremotelogin on

## Set ARD settings
/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -activate -configure -allowAccessFor -specifiedUsers
/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -configure -users admin -access -on -privs -ControlObserve -GenerateReports -OpenQuitApps -ChangeSettings -DeleteFiles -TextMessages -RestartShutDown -SendFiles

exit 0

It has been working fine for all our Sierra Macs. But it looks like it's not really working for this new Retina MacBook Air with Mojave that we're testing.

[GabeShack]

@itupshot If you want it to just work like it used to you just have to boot into recovery on the new system and disable all the security settings (basically turning off SIP). This adds an extra step, but your user logins will work even with user template fillings once this is turned off. I would not recommend this unless temporarily as Apple may break it soon.
See this article:
https://support.apple.com/en-us/HT208330

Gabe Shackney
Princeton Public Schools

[itupshot]

@gshackney Well, we're trying to do this the fully-supported way now.

The computers that are giving us the most issues setting up now are the 2018 MacBook Air (Retina). We can't netboot them to launch Casper Imaging to run the PreStage Imaging just to deploy our software. We're trying to figure out what will work given the new limitations.

Configuration Profiles can be very restrictive because they don't have the "Once" key, so I may need to script a lot of these plists to be inserted when we first log in a user.

[GabeShack]

Right @itupshot , you would need to set all the pieces of the image to be policies that run at Enrollment complete. Then wipe the unit using recovery or internet recovery, then enroll it in dep and set a prestage Enrollment and not a prestage image. The only issue we have currently is setting the name of the unit since all our other policies are based on the device name, but we adapted a script to run as the first "Enrollment Complete" policy.

This prompts the user doing the enrollment to type the correct name and then applies it before the rest of the policies run. Im still playing around with timings and performing a recon (which might not be a good idea) before all the other enrollment complete policies run.

#!/bin/sh
computerName=$(osascript -e 'tell application "SystemUIServer"
set myComputerName to text returned of (display dialog "Please insert Computer Name with Barcode (I.E. HS-Teacher12345) and click Submit." default answer "" with title "Asset ID" buttons {"Submit"} with icon caution)
end tell')

/usr/sbin/scutil --set ComputerName "${computerName}"
/usr/sbin/scutil --set LocalHostName "${computerName}"
/usr/sbin/scutil --set HostName "${computerName}"

dscacheutil -flushcache

echo "Computer name has been set to "${computerName}""
echo "<result>scutil --get ComputerName</result>"
sudo jamf recon

exit 0

Gabe Shackney
Princeton Public Schools

[goffja2000]

Hi,

Sorry to revive an old thread. I found a couple of policies at our school that were placing files in the Cookies folder. I've corrected them but still receive the library repair screens. The systems do work fine after a restore though. Is there a way to correct this without restoring the Mac? So far I've tried going into the User Template folder as root and deleting the files that my packages added to the Cookies folder. I also deleted the user account and home folder but still get the Library repair screen when signing in.

[RedWings]

@goffja2000 The only way to fix this issue is to re-image. The issue is that Apple does not want us writing to the User template. I am still able to create Composer installers that write to an existing User's folder (FEU), you just can't write to the User template (FUT).

[FutureFacinLuke]

Is this unique to Mac with T2 (in my case 2019 MacBook Pro 15")? A group OF MacBooks with the same set up as a group of iMacs has been hit by this but the iMacs don't suffer despite some policies FUT DMGs.

[GabeShack]

iMacs don't have T2 chips (except the Pro), but its also about if a change is made to a users library folder (IE you have something set to Fill templates), to fix you can either disable SIP or reimage without filling the user template.

Gabe Shackney
Princeton Public Schools

[allanp81]

@RedWings That's not true. I still do plenty by writing to the User Template without any issues whatsoever.

[GabeShack]

@allanp81 Its only certain things in the User Template that don't affect it currently, but this is not something I'd recommend you keep doing for the long run. It will eventually break, and its probably better to find your work arounds now. Between SIP and the T2 your almost guaranteed to have issues going forward playing with the user template.

Gabe Shackney
Princeton Public Schools

[allanp81]

I don't see why, depending what you do. I generally only use it for populating things in preferences to make software work, or occasionally populate things in the documents folder if an app needs something there.

[GabeShack]

Because of the above. Thats a folder that SIP tries to keep exempted, but changes still can cause problems depending on usage (specifically one I know of is Safari preferences being filled in User Templates) and will flag as a bad library when the user logs in. Otherwise Apple doesn't support changes to anything in /System. Many of the discussions of SIP and T2 security here on jamf confirm this and I would say most have moved away from FUT deployments. There are other workarounds and its all very annoying, but again probably better to be ahead of this.

Gabe Shackney
Princeton Public Schools

[allanp81]

@gshackney Apple's documentation is a bit vague with regards to how much of /System is actually protected. Their page https://support.apple.com/en-gb/HT204899 suggests that the whole of /System is protected but obviously that's not the case.

[GabeShack]

@allanp81 For a bit of a deep dive perhaps take a look at SIP security which is a great write up by our friend @rtrouton
He shows how to identify SIP exempted folders in /System . I think based on the above article though Apple states the entire /System is protected, which I take as "it will eventually be true".

Gabe Shackney
Princeton Public Schools

[allanp81]

User Template is now located outside of /System by the look of it in Catalina.

[allanp81]

@gshackney Looking at the docs on rtrouton's site also suggests that /System/Library/User Template isn't included in the protection. I've confirmed this on one of my devices by checking the rootless.conf file and seeing the asterisk before the listing.

[RedWings]

@allanp81 Since we stopped writing anything to the User Template, our issues are all resolved. All we were writing to them were preferences. Either way, I've talked to a former colleague of mine at Apple and he confirmed that Apple does not want anything writing to the User Template.

[allanp81]

Why did they explicitly exclude it then?