Keychain Folder not properly created.

Sounds like when you were in composer you click Build OS Package but when you clicked next there is a bunch of check boxes the key box to uncheck is the Remove Kerberos Certificate. I had a problem with my wireless password not getting saved because of this option. Also the problem could be if you are modifying the default user template..

Thanks for the reply BM. I did try creating a new image with Kerberos unchecked and still get the same results. Since Binding is included in the configuration that I have, I figured I'd try all possible binding scenarios. I did it separately after an image and that time it worked. Thinking this might be a good work around for now, I tried another, installed the other software needed, Bound to network and then logged out to test it and once again I get the same keychain errors. Not sure where to go now.

I too am now getting this same behavior with 10.7.5 machines. These have been bound and running for a few months and this has just recently started up. The keychain folder is not being created from the default template for new users.

HI Kprice, I have many of my apps set to FUT and had been running fine for quite some time. It was a recent development and could indeed be a newer package set with this setting that has caused the problem but I hate to have to go back to reimage everything! I'm thinking I may try to add a keychain folder in the user template that would simply be pushed out on login. Will post back.

Just to try something I went to my pristine test unit, logged in as root. Installed composer and admin on it - created a package by just adding a folder "Keychains" in the user template library.

Saved it as a .pkg and installed on a few systems and it took care of the problem.

Not elegant but it does work.

I know this is an old thread but I am having the same problem. All of a sudden any new users logging into my OS X 10.9 devices were getting an error regarding the login keychain. I tried creating the login keychain manually through Keychain Access but it still wasnt working. I realized that it created the login keychain in the user's Library folder because there was no Keychain folder. I manually added a Keychain folder for that user, moved the login keychain into it and everything was fine for that user.

Since this is only affecting a handful of new users that never logged in before, I'm assuming I pushed out a package that wiped out the user template keychains folder. I saw the "fix" by creating a package to place a keychains folder in the User Template but I thought I would already see a KeyChains folder in the User Template on a newly imaged machine but it doesnt exist. Yet since I have not push out any packages to it yet, users can login and their login keychain gets created no problem. Where is it getting the preference from?

Also if I create a policy to push out a Keychains folder to the User template folder, wont that only fix any "new" users logging in. We are using Mobile accounts and there are existing accounts that are missing the Keychains folder. Do I have to make a second policy to place a keychains folder into any existing User profiles as well or delete the existing user profiles? And what happens if I do push a Keychains folder to a user's profile that happens to already have a Keychains folder and working fine? Will it merge the two or overwrite it causing the existing login keychain to get removed?

I'm trying to figure out how to target this policy or if I should make it a self-service policy to be used on problem machines only.

Any help would be greatly appreciated. This has been very frustrating to say the least.

Thanks

Mark

Posted: Less than a minute ago by 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...

There is a Stickies database in there that is not a folder, all of those other white files should be folders, including the Keychains folder.
I have added the Keychains folder to the Templates, and fixed that problem. The others I run a Login script and it finds every file in there apart from the Stickies database, and deletes it and recreates a folder of the same name. This fixes a multitude of problems, like Calendars not working. And this works in all versions of OSX to 10.14
The Keychains one, if you get it, has a trick to it. Apple seems to think that with a brand new account, at first log in, we want Safari open, Not found a way round this one yet. If you try to sort the folder out whilst you are at this point the warning will keep on popping up on you about 10 times. Just cancel it and Quit Safari until it all stops. Now you can reset the file to be a folder, and then open Safari, it will ask you to reset and then it will go away and not come back.

$theuser is the current user logging in on the Mac. The IF is just to check if the result you have is empty or not, no point continuing if the list is empty.

CSGSEARCH=$(ls -p /Users/"$theuser"/Library/ | grep -v / | grep -v StickiesDatabase)

if [ ! -z "$CSGSEARCH" ]
then
for FILEHUNT in "$CSGSEARCH"
do
# This is a file convert it to a folder
/bin/rm -Rfv "$FILEHUNT"
/bin/mkdir "$FILEHUNT"
done
fi

@mhegge I too have found this to be the case but MAINLY with Apple software as they are locking down the user template folder which FUT is using. Programs from Apple are becoming very restricted in messing around in their use.

After working with an Apple tech engineer, he told me this is case for Apple software like Safari and such. I am currently working to see how I can move away from using FUT, FEU and the user template folder itself and begin using Outset.

Once I removed the Apple specific app user template folder/files from my packages, things began to work again.