Keychains folder changed to document

[luke_j_nelson]

Odd problem here...

Login keychain doesn't get created upon first login. It appears the folder the login.keychain file is supposed to be located in has been converted to a file (/Users/username/Library/Keychains). Any idea how this has happened, and how I can prevent this? I looked in the User Template, and the Keychains folder/document doesn't exist.

[ckeenan]

Did you find a fix for this? We are seeing the same problem.
Thanks-
Colleen

[luke_j_nelson]

Only fix we can find is to delete the Keychain folder, and when they log back in it will create the folder again along with the login keychain.

Someone here said he thought it was McAfee doing this. A certain update maybe?

[tu-egadsby]

I am having the same issue. I tried to build a package to replace the folder but that didn't work. Any help would be appreciated. Thanks!

[emily]

I just had this happen to me! What is the deal?! Anyone find a root cause?

[GabeShack]

If you edit the User template and just create folders for all the things that are being created as files seems to fix the issue.

I believe some of the folders in the default template are: /Library/Application Support/AddressBook
/Library/Application Support/SyncServices
/Library/Calendars
/Library/Mail
/Library/Keychains

Gabe Shackney
Princeton Public Schools

[Chris_Hafner]

Also, try to avoid using FUT enabled installers during imaging. If you're distributing a non-booted OS the template folders may not be created by the time your installer goes looking for them. I've seen this cause issues in my experience.

[cwaldrip]

I've been trying to figure out why this is happening to me too. I don't think any of our installers are breaking it (but probably).

For those wondering, this seems to be a complete list of the 'broken' folders.
~/Library/Application Support/AddressBook
~/Library/Application Support/iCloud
~/Library/Application Support/SyncServices
~/Library/Calendars
~/Library/ColorSync
~/Library/Components
~/Library/Dictionaries
~/Library/KeyBindings
~/Library/Keychains
~/Library/Mail
~/Library/QuickLook

[rlindenmuth]

I had this issue crop up this week and a FUT enabled .dmg in the "image" process is what broke it. I removed it from the config and the ~/Library folders resumed being created as they should.

[mhegge]

Refreshing an old post here, but I am seeing this in High Sierra.

Upon upgrading computers to High Sierra or Re-imaging to High Sierra (Netinstall macOS, enroll, then Policies) and binding computers to new domain.

Getting the following.

There are at least a couple Policies with FUT but that does not account for computers that were just upgraded as apposed to imaged and had the policies all deployed fresh.

I can delete that keychains ghost file and the account (my account) can log in without the error. But we have students logging in and that is not a good situation...

[mconners]

All, it is appearing Apple is locking down the user template folders more and more. Almost all Apple apps such as Safari will create issues if they write files into the user template folder. Those .dmg packages that write to FUT can cause issues. I had settings created for Safari, Compressor and other apps that cause the keychain to get borked.

There is another discuss here.

The bottom line is move away from using the user template folder for anything related to Apple apps. 3rd party apps continue to work, mostly though.