Peter Bruderer
Level 1
(8 points)
Since the upgrade to 10.9.4 I'm asked to enter the password for the keychain every time I reboot my machine.
I use portable Home Directory and iCloud keychain sync.
So far I have not yet found a solution to bypass this problem.
Does anyone else have this problem?
Q: Home Sync wants to use the Login Keychain
nick-without-a-name wrote:
Since we all know the issue was introduced in the MacOSX10.9.4 update (if I recall this correctly), would it be possible to run a pre 10.9.4 version of the ManagedClient app on Yosemite of El Capitan? That would be an interesting test.
This issue has existed on prior OS's. My guess is that the 10.9.4 update & your issue are a coincidence but if you have time & pre 10.9.4 installer you could test it I suppose. I saw this with 10.6 & others in this thread have mentioned the error going back to 10.4… It may be something that is an interaction between caches that got rebuilt as part of the update etc.
You could try running a diff on the the versions of Managed Client.app if you think the error lies in that component, I'm just not sure what you would find via that.
OK, Well day two of multiple login's and log outs on both machines with my test account and, so far (touch wood!), no nasty pop ups. (Sadly, I find myself holding my breath until the login is complete and I've confirmed there is no request for access to a Keychain!)
Having done a little more testing with another account, while I agree with Nick-without-a-name's comment that the command used is the same as is run by the GUI, (although the exception being the GUI adds the equivalent of the -P flag which is prompt for user password), there is one notable difference that may be the key:
The GUI method is run while logged in as the user for which the mobile account is to be created, which then forces a logout and a home directory sync. Seeing as it is a logout, both the home directory and preferences are synced. Having checked the ~/Library/Preferences/com.apple.homeSync.plist that is created via either method, the default preferences are the ~/Library folder with a few exceptions, however, the Keychains directory is NOT one of the exceptions - this is synced.
I will admit I do not know how Keychains are created (as in what information is used in the creation), but I suspect that some information relating to the machine they are created on is used (Disk GUID perhaps?). This is based upon the method described by Apple themselves if transferring a keychain:
Keychain Access: Copy keychains to another Mac
Whereby it isn't simply drag and drop. I am wondering (and again, purely speculation) whether the way the keychain is created while connected as a Network user causes corruption during this initial sync which pulls it from the server to the local machine that results in the pop ups we have all come to know and hate. The creation of the portable Home Directories using the command as I previously listed does not force this initial sync since you are logged in as local admin user and as such, the keychains are created and stored locally anyway. I accept that this would suggest purely deleting the Keychains folder on each machine should fix the issue and we all know it doesn't, so hence I am not convinced, but perhaps food for thought.
The other possibility I can see is that the GUI method doesn't run the command as root and this somehow corrupts the process irreparably. (I merely mention it as unless the Admin password is cached from unlocking of the User & Groups preference pane, the password is not prompted for - which from the GUI is unusual).
Thoughts? Please feel free to shoot down the suggestions above, but all I know is that, so far (again, touch wood), having created the mobile account using the terminal I haven't had a re-occurrence, and that makes me very happy
thanks for the post jpparellel, I will give this a go if I have time over the next few days.
Are you still clear of the keychain popups?
Our setup is slightly different in that we use mobile instead of network accounts and do not have AD in the mix so everything is dealt with by OS X server. However, this issue clearly persists across both types of accounts so it'll be interesting to see if this method has a positive effect. Once I clear some time I will give it a go and report back.
@JAGUK: it maybe a terminology issue, so apologies. In my view:
Network account: logged in from a client machine as a user stored in the Active / Open directory. No ability to login off network.
Mobile account: logged in from a client machine as a user stored in the Active / Open directory, with a synced home directory allowing login off network.
Local account: logged in on a client machine as a user that only exists on that machine. This user is NOT authenticated against the Active / Open directory
In answer to your specific question, I've probably logged in and out of both an iMac and MacBook Pro about 4 or 5 times each today as my test account (allowing syncing to finish every time) and still no pop-ups. Just as it may well be relevant (although even when setting up through the normal GUI method I had these settings), my current sync settings (which were setup within 1 or two logins on each machine) are, as per the GUI:
Sync automatically
At login and logout
Only selected folders: (I have ONLY DESELECTED Library - all other folders are still ticked) - this disables preference syncing.
agree with you 100%! I only mentioned we were using mobile accounts as I thought your setup mentioned that you were using network type accounts which have their home directory stored on the server. If I misread or misunderstood your original post, apologies! I will have another read ;-)
It's really good to hear that you have carried out multiple logouts (are you rebooting also?) without the popups returning... this does sound promising
I threw together a script for doing this in case anybody is not that good at the command line... actually I did it so I could contribute to this solution.
#!/bin/bash
if [ "${EUID}" -ne 0 ]
then echo "Please run as root or use sudo"
exit
fi
USER="${1}"
if [ -n "${USER}" ]
then
/System/Library/CoreServices/ManagedClient.app/Contents/Resources/createmobileaccount \
-v \
-X \
-s \
-n "${USER}" \
-h "/Users/${USER}" \
-u "smb://benzaiten.rearviewofagenius.net/Users" \
-t "${USER}"
else
echo "A user must be specified"
echo "$(basename ${BASH_SOURCE[0]}) <user>"
fi
@sdf_iain: I understand that it takes out a lot of re-typing of the same things for every user, so good work. just a comment though: it might be worth mentioning line 17 needs changing to the correct sharepoint for the Network home location, I'm not sure everyone uses smb://benzaiten.rearviewofagenius.net/Users/
And does this mean you have tried this too and had the same positive results? That would definitely be worth sharing. Also, unless this has been tried, I'm not convinced this solution would work without deleting the original (broken) local home directory first. Happy to be wrong on that. Would make the fix a lot easier
I haven't received positive results (yet). Its all set up on my home network and I haven't had the free time to run any tests yet.
I'm going to have to create three test accounts and see how they behave:
On a side note, how do I edit a post?
sdf_iain wrote:
On a side note, how do I edit a post?
Quickly
You get 10 or 15 minutes if I recall correctly & it may get locked if someone replies directly to it.
Use the 'drop down triangle' below the post to select the edit option if available. Otherwise report the post (or ask someone to do that if you don't have the option). The moderators can edit out personal info.
hey jpparallel,
Unfortunately I'm not having any success with the MBP i've just been testing this with.
I first of all I tried creating a fresh mobile account using createmobileaccount (this test user did not exist on the MBP prior to this). This all went well until the first reboot, upon which i got the home sync popup. I gave a it a few further reboots but the popup persisted unfortunately.
I then tried removing the mobile user's home directory, following your guide, but upon issuing the createmobileaccount command again I got this error:
2016-06-24 14:55:41.145 createmobileaccount[710:8023] MCXCWriteUserRecordToHome(): Could not write new file at "/Users/fredblogs/.account"
*** "/Users/fredblogs/.account" could not be written
I suppose the next test it to try this all again but on a pre-existing mobile account added in the traditional method.
Hi JAGUK,
So you got the pop up on the first reboot following creation? That's a shame.
Just to check (and I appreciate some of these are very low level questions):
The account used already existed on the server? - I presume yes as otherwise I would have expected a username=null error
Did you log in as the user on the MBP prior to attenpting to create the mobile account? Just just wondering whether this is a necessity for any reason.
Did you run the command as root / with sudo? - again I presume yes (not sure it can be run otherwise)
What flags / options did you use? I don't need the parameters, just the switches, e.g. -vsXn -h -u -t etc
Did you give the user admin rights? Not sure this is required either.
When you removed the home directory, did the user still appear in the Users & Groups preference pane on the MBP? I know I didn't reference removing them from here, but thinking about it, given my preference to place the home directories on a non-boot volume, when created through the GUI, they are not added in the preference pane as visible to other users as they are added as external users. I'm thinking this may be the cause of the "unable to write file" error.
My suggestions would be,(if you haven't already done this):
With the account that exists on the server:
Using a local admin account on the MBP, ensure the user does not appear in the Users & Groups preference pane
Using a local admin account, sudo rm the users home directory, if it exists
Log into the account on the MBP purely as a network user.
Log out and back in as the local admin account
Run the createmobileaccount command as sudo / root using the vsXn h u flags with correspinding values (Just as my explanation)
Log out of local admin
Log in as mobile user
Log out from mobile user - DO NOT REBOOT
Log in as mobile user
Amend sync settings using the GUI to remove ~/Library (Leave all others checked)
Log out as mobile user - DO NOT REBOOT
Log in as mobile user.
Then perform a reboot
Log in as mobile user.
If you get the pop up at any stage, let me know. I'm hoping not, but if you do, I guess I've been lucky in my tests and we are back to stage 1
hey jpparallel,
Thanks for the reply! All good mate, happy to answer any questions... we have to cover everything off!
1. Yep, all accounts are local network accounts on the server
2. No, i didn't log in the traditional manner on my initial test - i thought I may as well test it by creating the account from fresh via terminal. However, after the first test resulted in a popup, i then fully removed the account and tested the process again this time creating the account via the traditional method and then following your guide. Both tests resulted in a popup on first reboot.
3. Yes, run as root
4. I used exactly the same options / switches as you did with the command
5. On the initial test, no I didn't add admin rights. On the 2nd test I did add admin.
6. Yes the user still appeared in User & Groups but I would have expected this as your test did not mention removal of the user account from there.
Out of interest why do you place home directories on a non-boot volume?
I wasn't totally sure about your point about the mobile accounts not being visible (within Users & Groups) to other users - if I'm understanding this correctly, this doesn't seem to be the case at our end as the mobile accounts are always visible to the local (admin) users. Obviously you have to be an admin to unlock the Users & Groups pref pane to be able to see other users on the Mac. Am i missing the point here?! We do not use local accounts on our Macs (other than default admin) so this might well be true!
I will test again now following your suggestion to the letter. I will report back ASAP!
hi again,
OK so I followed your suggestion and after the first restart I got the setting up new account screens etc without any subsequent popups (same with my previous tests)
The next reboot brought back the popup unfortunately.
One thing immediately springs to mind where our setup might differ from yours: we are using profiles to set which directories are set for HomeSync (just Desktop and Documents)
To remove the profiles out of the equation I would have to remove them so that I can set the sync settings manually and test again