@johnmcnair It was a config xml file that pointed users at a server for an app, locked via Finder (or chflags uchg) so that people couldn't modify it unintentionally. File was stored in user's library, with perms 755. Owned by an admin user (FEU/FUT was used previously, and file was from 10.5 template.) which was retained as owner due to lock.
@JesseNCSD I'm curious to know how you went about finding/fixing this issue?
I've ran into this issue before.
Does the problematic file come up when you verify/repair permissions? And what's the best process to repair the file?
@McKinnonTech I used the split-halves method for tracking back the package responsible. I had been reading through related threads for this sort of issue, and people suggested permissions/package problems or AD/fileserver stuff. I figured funky permissions in a package was a possible culprit, given that it affected local users too.
Once I identified the responsible package, I repackaged it without the locked file.
Perhaps there was something corrupted with the original package also? I can say for sure that 10.11 does not like copying locked files on creation of user from template - for the existing users that had the problem on upgrade ... got me. Maybe an intersection of two unrelated issues?
@JesseNCSD wrote:
I used the split-halves method for tracking back the package responsible.
Goose bumps...thinking of Conflict Catcher...
FWIIW (adding some data, though probably not adding any solutions):
One thing I will state from reading this thread (that I think only a few people pointed out): this error is a “general” error message for a behavior that can have a number of causes.
When I have come across the error, the outward behavior was that the home directory was not completely propagated (for example, only Library, Documents, and Desktop). In my experiences, there were no AD mobile accounts in play, just a local admin account.
I am also inclined to recall that I did not have the error in greater numbers because I deliberately introduced an extra restart into the imaging process (no particular reason: I was working under the theory that, since a restart can fix a lot of problems for a computer when it is in a user’s hands, it can also help prevent problems from being creating).
Seeing this in testing out-of-box El Capitan self-upgrade process. Out of curiosity we decided to run some consistency tests to see if we can narrow down the culprit.
To ensure we follow a deliberate/exact testing process we used:
- MacBook Air (128 SSD) for speed
- OOB image of Yosemite (10.10.5) created using Per Olofsson's awesome AutoDMG.
- JSS dev environment 9.92
Dropped the OOB image onto the MacBook Air, created testuser, enabled for SSH. Enrolled it to JSS, scoped it to our El Capitan self-upgrade test policy (cache; then install cached).
After upgrade completes, we log in as testuser, we get the dialog box, and we stop. We SSH in and look for anything in /Users/testuser/Library that isn't owned by testuser and found some stuff that was put there by vanilla third party package installers (that did not present any issues in testing/deployment):
bash-3.2# find /Users/testuser ! -user testuser
/Users/testuser/Library/Group Containers
/Users/testuser/Library/Logs/FlashPlayerInstallManager.log
/Users/testuser/Library/Logs/ReceiverInstall.log
/Users/testuser/Library/Preferences/com.apple.SetupAssistant.plist
/Users/testuser/Library/Preferences/com.jamfsoftware.selfservice.plist
bash-3.2# ls -l /Users/testuser/Library/ | grep Group
drwxr-xr-x 3 root staff 102 Sep 10 01:56 Group Containers
bash-3.2# ls -l /Users/testuser/Library/Logs | grep FlashPlayerInstallManager.log
-rw-r--r-- 1 root staff 336 Sep 10 00:38 FlashPlayerInstallManager.log
bash-3.2# ls -l /Users/testuser/Library/Logs | grep Receiver
-rw-r--r-- 1 root staff 1583 Sep 10 02:00 ReceiverInstall.log
bash-3.2# ls -l /Users/testuser/Library/Preferences | grep com.apple.SetupAssistant.plist
-rw------- 1 root wheel 343 Sep 10 02:36 com.apple.SetupAssistant.plist
bash-3.2#
We stopped there and restored the MacBook Air to OOB state for another test.
This time we used a Before script in the El Capitan self-upgrade Cache policy that looped through all user accounts to recursively chown each /Users/$user/Library folder to ensure its owned by $user. Ran through the upgrade, and bingo, no prompt to repair Library folder on login.
Ran through the first test again to confirm, got the Library permissions error.
Ran through the second test (with fix) to confirm, did not get the Library error.
What does this mean? It means I need to get off my butt and enjoy the weekend, and come back to tackle this on Monday. :)
Planning to test again on Monday, responding to the dialog box to see what actually gets/got repaired.
Don
Well, recursively setting /Users/testuser/Library to owner testuser fixes wrong ownership except for one file that keeps setting itself to root owner...
bash-3.2# find /Users/testuser ! -user testuser
/Users/testuser/Library/Preferences/com.jamfsoftware.selfservice.plist
bash-3.2# ls -l /Users/testuser/Library/Preferences/com.jamfsoftware.selfservice.plist
-rwxr-xr-x 1 root XXXXDomain Users 573 Sep 11 17:02 /Users/testuser/Library/Preferences/com.jamfsoftware.selfservice.plist
bash-3.2#
We'll get a ticket open to support in the morning.
Don
FYI, we confirmed on several dry runs today, that /Users/testuser/Library/Preferences/com.jamfsoftware.selfservice.plist does not cause the permissions issue.
Although curious why it has to be owned by root. We'll open a ticket to see if this is a defect.
Don
Has anyone figured this out?
After migrating from MacBook on Sierra which is binded to AD is having the same issue.
I haven't come across this on El Capitan, it only seems to happen to Sierra.
@macsadmin I just confirmed this for us as well when imaging a fresh machine. Our JSS is a bit out of date (9.82) and did it with both 10.12.0 and 10.12.3. IIRC, in my very prelim tests with Sierra on this same JSS version I did not run into this issue. Only now.
Very minimal image, so I don't think it's software, but going to keep testing.
When I login with a local user that gets created post image I get no prompts about needing to repair Library permissions.
When I login with an AD account I get the error. Running an ls -lah on the AD user's ~/Library folder I see that rather than our standard DOMAINDomain Users group as the primary group, I see sys as the group. We do a few things in the User Template, but I confirmed that both the stuff we add and/or modify as well as the default Mac settings are all set root:wheel.
So this appears to be a macOS AD group issue?
We do a few things in the User Template, but I confirmed that both the stuff we add and/or modify as well as the default Mac settings are all set root:wheel.
Default User templates are not used when users log in with directory credentials via default AD bind. If you enable "Mobile Account" creation at login, it will apply the Default User Template - but this results in a local cache being made of the network account, and you have to potentially deal with how a mobile account operates. (Unless I'm confused.)
This difference can result in different behavior between local user/"true" mobile/mobile with forced local home and network home only logins.
If you're having permissions issues with network home, non-mobile accounts - I'd look at how your permissions are defined on the fileshare and potential issues that may arise.
When I moved into later versions of macOS, I found I had problems in our environment and items being set with improper permissions due to issues with SMB and permissions creation on our Macs vs Windows fileshares.
@JesseNCSD We do create Mobile Accounts at login. We don't use network homes.
@aporlebeke Funky you're seeing no issue on locals and issues on mobiles! Does the account structure get fully created for newly logged in mobile accounts?
Sure enough, it appears it did not create the Mobile Account at all or the home folder.
So, I was able to resolve this for us! Hooraaaaay! Details below. Hope this helps other people.
The short and sweet version:
The configuration profile that configured our login window had the “Combine available workgroup settings” checkbox unchecked. Pushing out an updated profile and changing just this setting stopped the Library repair message from appearing. Ultimately, this appeared to be a workgroup setting issue with the account I was using (my own), as I am a part of many different groups and nested groups.
The detailed version:
After closer examination I noted a couple things:
The account I was initially testing this with was my own AD account, for which I am a part of many more groups and nested groups than a standard user would be in AD. Without making any changes to my test computer, I tried logging in with two different basic testing accounts and did not have the same Library repair errors as I did with my own account and confirmed that cached mobile accounts were created. I wiped and reimaged this test computer again and got the same results.
When I was logging in with my own account, I would get a Workgroup popup message similar to the one below, which I had not seen before. I did not see this message when I logged in with our two basic testing AD accounts. Choosing either Continue or Remember and continue when I attempted to login with my own account did not stop the Library repair message from appearing.
I had a hunch this might be something profile-related and checked our configuration profiles. I noted in the Login Window payload under Access that neither the Ignore workgroup nesting or Combine available workgroup settings were checked.
To test, I cloned this profile, scoped it to our test machine, and checked the Ignore workgroup nesting while leaving the combine setting unchecked. This did not stop the message from appearing for my AD account nor created a cached mobile account.
Then I tried checking the “Combine available workgroup settings” and leaving the ignore nesting setting unchecked. Unlike my first test, this change stopped the Library repair message from appearing and successfully created a mobile account for my own AD user!
We are currently still on 10.11.6 and this was not previously an issue.
So it appears that for us this was a niche-case workgroup issue with an AD account that was part of many groups and/or nested groups.
Suspecting a permission issue, I was hoping to run the disk repair permissions option in Disk Utility, however I am running mac os Sierra and that feature has been removed. My only alternative was to reinstall mac os — so I did. Unfortunately, this did not fix the issue either — likely because the reinstall intentionally does not mess with existing home directories.
Running out of options, I decided to fix my home directory permissions via login with root user or other administrator profile.
When I rebooted, I was happy to see that my profile was returned and the pop up was gone. Root cause was the installation of VMware Fusion :)
