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?

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.

@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.

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.

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

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

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

@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.

@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?

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.

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.

@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

@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.

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

@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.

@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.

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.

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?

@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.

@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.

@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

@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.

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

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.

@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).