OS X need to repair your library (after Mojave upgrade)

[glpi-ios]

Hi,

I was in MacOS 10.13.6 and since I updated to Mojave, everything works exept when I create a new account (AD or Local), I have this message : "OS X needs to repair your Library to run applications. Type an Administrator's name and password to allow this".

And when I look the user folder's permissions, I can see "Root" is owner and no user.

is it a "User template" issue ?

I have to upgrade 1400 computers, how can I resolve this ?

Thank you for your help

[alexjdale]

Yes, it's a user template issue. The OS does not re-permission the files after it copies them into the new user folder. I reported this bug to them in beta.

Don't use templates anymore, basically. You can delete the user template folder you were using and new users will be created correctly (I haven't seen any issues with this yet).

[SGill]

I saw the same thing, and when I narrowed down what part of the user template was causing the failure in Mojave, I found that it was actually only the Safari folder causing the issue (with a custom Bookmarks file I wanted to give to users) in my case, at least.

Hoping to move past using the template soon, too.

[mbezzo]

Ooo, good info @SGill. If that's the only thing (of course may be others...) causing issues that would save me a ton of time short term! They always said "don't mess with the user template folder!" And, FINALLY... those folks can say "I told you so!" Hahah. Took long enough... ;)

[glpi-ios]

Thanks for your help.

Despite the removal of the entire content of the User Template (/System/Library/User Template/French.lproj/*), I still have the problem.

When creating a new profile, the message always appears and I can see that it creates the folowing folders with owner 'Root' 700 :
Documents
Desktop
Library

[glpi-ios · Accepted solution]

Hi everybody,

After hours of testing, I found the culprits

/System/Library/User Template/Non_localized/Library/Application Support/com.apple.TCC
/System/Library/User Template/Non_localized/Library/Application Support/AddressBook

When I delete these two files, everything works again.

I know that I should avoid touching the 'User Template' as much as possible, but I try to use it as little as possible.
The problem is that there are still some settings that we want to use by default in our company that I still can't integrate into the Jamf Pro configuration profiles.

I try to migrate to the maximum each setting with scripts and configuration profiles ...

Thank you all for your help.

[mconners]

Hello @glpi-ios it's good to know I am not the only one with this problem. Today I will work on this so thank you for your guidance.

One other thing, do you have a way around the feedback assistant? I wonder if I could simply delete the application altogether and still have Mojave work?

Thanks again!!

[glpi-ios]

Hello @mconners

'Feedback Assistant' is not just for Beta version of MacOS ?

[mconners]

Hello @glpi-ios Apple and I thought the same thing, but with the version being installed from an install we downloaded from the App Store, it is in fact there and prompting our users.

[glpi-ios]

@mconners

It's weird ... I don't have it.

Can you check the 'software updates' pane in system preferences if you see the message "This Mac is enrolled in the Apple Beta (or Developer) seed program" ?

Otherwise, I don't know if removing the application can be done without impact for system, sorry.

[mconners]

Hello @glpi-ios that was it! Thank you, that helps out so much!! I didn't see it there originally, but I will fix this ASAP.

[dpratl]

Hi all,

I have the same problem with a fresh clean install of Mojave.
If i remove all in /System/Library/User Template/ a new user can login and the Error message is gone (thank you for that)

BUT: If i take a look at the permissions in /Users/ the user Folder are created with wrong owner.group

drwxr-xr-x   4 root    admin   128 Nov 13 12:04 user3
drwxr-xr-x   6 root    admin   192 Nov 13 11:57 user2
drwxr-xr-x   8 root    admin   256 Nov 13 11:44 user1

We are using AD user (our Macs are bound to AD) and it should look like that:

drwxr-xr-x+ 52 user1  DOMAINNAMEDomain Users   1.6K Nov 13 12:48 user1

Do you have a clue how to fix that?

Thank you
BR
Daniel

[stevewood]

@dpratl

When you say "...fresh clean install of Mojave." are you installing anything or putting that machine under management with jamf at all? To me that means you wiped a device, installed Mojave, and then created a user, but it sounds like you are at a minimum binding the device to AD.

If you are enrolling the Mac in jamf and allowing packages to install and the machine to bind via jamf, I would first test by not enrolling in jamf and manually binding to AD. That will tell you if this is a Mojave issue or an issue with something you are doing via jamf. Once that is validated to work (no enroll, manual bind), I would then test enrolling and binding via jamf, and not installing anything. If that works, then start adding software one by one until you find the culprit.

My guess is that you have a PKG or DMG that gets deployed via jamf that is touching the User Templates folder. Once you identify that item, get rid of it. As mentioned above, you should not touch the User Template folder. If you need to make a change to a user do it via Configuration Profiles or scripts. If it's something that has to be replaced in a user folder, use a login script via Outset or a jamf policy set to login. But whatever you do, do not touch the User Templates folder.

[dpratl]

@stevewood

Yes, I meant a fresh Mojave installation and a full enrollment afterwards.

Oh my ... you are right :(
I have deactivated all FUT Policies and now the user creation is working.

I wasn't aware of problems with FUT, thank you for the input. I will change these Policies and implement them into my First Run Procedure and only use FEU.

BR
Daniel

[lrabotteau]

Hello,

I've got the same issue

What I'm supposed to have in Non_localized folder ? I've deactivated all FUT Policies but this issue is still occur.

Regards,

Ludovic

[joelsenders]

Just to add to this, since it doesn't seem like anyone has pinpointed exactly what is going on here... The issue doesn't actually appear to be with the user template at all, but instead with the way Mojave handles user folders. User home libraries appear to have a bunch of directories protected from various interactions. This is likely what is causing the library repair dialog on login if you've modified the default template.

Here is a test you can run to see what I'm referring to:

1. Without having modified the default template, create a new user
2. Log into the new user account (in order to generate all ~/Library files and directories)
3. Log out of the new user account
4. Log into a different admin user
5. Open terminal and run:

sudo chown -R admin:staff /Users/newuser

...where "admin" is a pre existing admin account and "newuser" is the new user account you created in step 1. Notice you will be prompted by PPPC to grant Terminal access to Contacts, etc. Terminal will spit out these errors (possibly more depending on your context):

chown: /Users/newuser/Library/Application Support/CallHistoryTransactions: Operation not permitted
chown: /Users/newuser/Library/Application Support/CallHistoryTransactions: Operation not permitted
chown: /Users/newuser/Library/Application Support/com.apple.TCC: Operation not permitted
chown: /Users/newuser/Library/Application Support/com.apple.TCC: Operation not permitted
chown: /Users/newuser/Library/Application Support/CallHistoryDB: Operation not permitted
chown: /Users/newuser/Library/Application Support/CallHistoryDB: Operation not permitted
chown: /Users/newuser/Library/IdentityServices: Operation not permitted
chown: /Users/newuser/Library/IdentityServices: Operation not permitted
chown: /Users/newuser/Library/Preferences/com.apple.universalaccess.plist: Operation not permitted
chown: /Users/newuser/Library/Messages: Operation not permitted
chown: /Users/newuser/Library/Messages: Operation not permitted
chown: /Users/newuser/Library/Mail: Operation not permitted
chown: /Users/newuser/Library/Mail: Operation not permitted
chown: /Users/newuser/Library/Safari: Operation not permitted
chown: /Users/newuser/Library/Safari: Operation not permitted
chown: /Users/newuser/Library/Cookies: Operation not permitted
chown: /Users/newuser/Library/Cookies: Operation not permitted
chown: /Users/newuser/Library/Caches/CloudKit/com.apple.Safari: Operation not permitted
chown: /Users/newuser/Library/Caches/CloudKit/com.apple.Safari: Operation not permitted

These directories appear to be protected somehow by macOS. I've tried other manipulations via scripting, such as attempting to remove the contents of the directories and replace them with modified items, etc. and still no go. Ownership gets all messed up on the home folder. You can't even run:

sudo ls -la /Users/newuser/Library/Safari

You'll notice again you're told the operation is not permitted. One interesting thing here is that it appears these folders can be viewed/modified just fine from the GUI, just not from the CLI. This was not the case in previous versions of macOS, so Mojave has some sort of new security feature built in which is meant to protect these directories from being modified via scripting.

This has some other implications as well, as sometimes I may copy a user folder from one machine to another, create a user with the same shortname so the home folder is adopted, and then run a chown -R to fix all ownership issues. It looks like that may not be a good idea in Mojave as these protected directories might not be granted proper ownership values.

In conclusion re: the information above, I'm assuming most people who are trying to modify the default template are running into trouble because they are supplying their own ~/Library/Safari folder. This is not going to be possible anymore now that this directory is protected. Interesting enough, the ~/Library/Preferences file is not a part of that protected list, meaning you very likely could still modify the default template ~/Library/Preferences files (such as the dock plist) and not get the library repair dialog. Likely, as long as you don't place any of the protected directories above into your modified user template, the protected directories will get generated properly on first login without any complaints. All that being said, this is a good time to start thinking about moving away from modifying the user template. It's clear Apple doesn't want us tinkering in there.

[waltnerc]

I'm experiencing the error messages on new mobile AD users via MacOS 10.14.2

I first manually upgraded to 10.14.2 on an existing mobile user's machine, and didn't see any problems with that user. (I'm going to guess that if I try to add another mobile user, that I will see the error on the new account.)
I then imaged another machine to a 10.12.6 build we use, then upgraded via USB boot to 10.14.2. Logged into the local admin account and performed a BIND to our AD.

I would then try to create a mobile AD user account from the login screen, and get a filevault message requesting admin access, then the error messages once I hit the desktop. I logged back in as the local admin, went to the user folder and for that specific user's subfolder (and all files / folders below it) performed a get info and added back read / write access for that user. I then logged back in as the mobile account. This time I saw all the getting started screens and the problem error message hasn't returned.

I'm not seeing how everyone is editing the user templates folder/files. It doesn't allow my local admin file permissions either in 10.12.6 or 10.14.2 and doesn't allow me to add file permissions via the gui.

My only concern is: Is the user's folder and subfolders the only file permissions that are impacted during the account creation process? I don't wan't to prep hundreds of machines over the summer to find out I missed something.

Christopher Waltner

[khurram]

The following prescribed solution from Apple worked like a charm.
https://support.apple.com/en-us/HT203538

[khurram]

@glpi-ios unfortunately the folder you deleted in your solution is inaccessible in first place

[trlatimer]

An easy fix for this that I have found is to use this: diskutil resetUserPermissions / id -u
I replace id -u with the id of the user you are trying to fix the issue for.
Say I'm trying to fix the issue for Bill, in terminal, "id bill" returns UID of 504. I would then enter "diskutil resetUserPermissions / 504"
This may work better for you than deleting the template files.

[thebrucecarter]

So, if you converted the hands on keyboard part of that process from Apple into bash, would it more or less be:

#!/bin/bash

CURRENTUSERID=`id -u`

cd ~

chflags -R nouchg ~
chown -fR $CURRENTUSERID:staff ~
chmod -fR 644 ~

diskutil resetUserPermissions / $CURRENTUSERID

exit 0

I know that the cd ~ is redundant, but I was trying to match the steps and still protect against cd failure in subsequent commands.

[trlatimer]

From what I have seen, I would believe it would work. I haven't used the chflags through chmod commands to resolve this issue yet. Simply running the diskutil command seems to resolve it for me.

[thebrucecarter]

Oops, possibly that chmod should be 755...

[khurram]

The easiest solution was to login as different user with admin rights. On the troublesome user folder right click --> Get Info --> Sharing and Permissions --> Unlcok --> click on the gears and finally apply permissions to the enclosed items. This fixed the problem in my case.

[trlatimer]

I have also had some success with the "Apply permissions to enclosed items", however, I have also had it not work and have had to use the reset permissions command as it didn't fix the full issue.

[syunetsy]

So I've been messing with user template folder hacks and noticed that if I disable SIP temporarily then create the local user account, the custom user template works, then I go and turn SIP back on and I can continue using the new user that was created by a custom user template folder with no issues.

This seems to work for me right now but I think it's only a temp workaround and zero/minimal touch is most likely the best method for future proofing the custom user experience setups.

[CasperSally]

@SGill are you still managing bookmarks in Safari in Mojave? I'd really like to not have to script to install for every user.

[SGill]

I still manage them for Safari on ethernet connected devices, but the issue described above really only becomes a problem (in my environment at least) on about 10% of laptops that are creating a new AD profile directly over wireless. Even an empty User Template folder (with only contents put there by Apple) on a laptop not connected to ethernet, will have the same occasional failure rate and the same error message (Library needs repair...). Currently my fleet is 5% Mojave 90% HS, 5% Sierra where I'm seeing these results.

[dogBother]

I've got the same issue and I believe it's related to our engineers pushing out Safari bookmarks but I want to find out how I can prove it's the bookmarks which is borking up the permissions.

[lauren_marsh]

@khurram was correct! https://support.apple.com/en-us/HT203538 100% works like a charm!