Hey Spraguga do you have a bug number for this defect from Apple? We are seeing the same issue at one of our sites which uses "unc path", and disabling it doesnt work to rectify the login hang without re-creating their account.
@dgreening You can delete the attribute using the dscl command to fix current users. Apple is aware of it. However, I'm not sure if it is on their official Radar bug list.
@dgreening Looked into this a little further. I'm not seeing anything for this in the open radar bug list.
http://openradar.appspot.com/
@spraguga What is the DSCL command to fix the current users?
See this discussion
https://jamfnation.jamfsoftware.com/discussion.html?id=12589
@spraguga][/url : Your post is much appreciated, and saved my organization lots of time. Thanks!
I used your knowledge as a starting point, and did a little more testing. I was looking for a way to avoid stripping out the homedir redirection, as many Mac users in my organization use that functionality. I stumbled onto a workaround that worked for me. I was able to confirm that the workaround is successful on all the Macs in my organization that presented the issue.
TL;DR
1) Login normally until you see the progress bar
2) DONT TOUCH ANYTHING until you see the spinning pinwheel of death (~60 to 120 seconds)
3) Hit enter (if it does not immediately work, wait ~90 seconds and hit enter again)
4) Profit.
Here is a write up of this, included for clarity. I honestly laughed out loud when I figured this out.
Issue: On Macintosh computers running OSX 10.10 (Yosemite), there is an issue with logging into an Active Directory account, when “off the wire” (i.e. not on the network with access to the location that the OriginalHomedir Attribute points to.) with FileVault enabled
Symptoms: Upon login attempt from cold boot, progress bar will quickly reach ~25%, and stop, followed shortly by the cursor turning into the Apple “pinwheel” and spinning. The spinning appears to continue forever.
Suspected cause: When logging in from cold boot, with FileVault enabled, 2 things happen: 1) Filevault disk lock is “unlocked”, and 2) login to the selected account is attempted. In cases where the home directory is an unaccessible SMB share on an Active Directory account, the disk will be “unlocked” and login is successful, but OSX will throw an error dialog stating that the SMB share can not be connected. Unfortunately, at this time, it spawns that error dialog behind the login screen, where the user can not see it, nor move focus back to it if initial focus is lost.
NOTE: If one were to “Login” from cold boot with a local account that does not have an SMB Share mounted as the home directory account, log out of the local account, and then login as the network account, the dialog is spawned in the correct GUI ‘layer’, and the user is able to see it and move focus on and off of it. In this scenario, it displays the same behavior of the spinning pinwheel until the “Close” button is pressed.
Workaround: When logging in from cold boot, enter password and hit the login button or press enter, as you would normally. Once you see the progress bar, it is imperative that you not click anywhere. The cursor will be drawn on the screen at some point; if it is not on screen after 10 seconds, move the cursor around till you can see it. In between 60 and 120 seconds, the cursor will start to pinwheel. Press enter. Login should finish almost immediately and drop you onto the desktop. If it does not immediately work, wait ~90 seconds and hit enter again.
TL;DR
1) Login normally until you see the progress bar
2) DONT TOUCH ANYTHING until you see the spinning pinwheel of death (~60 to 120 seconds)
3) Hit enter (if it does not immediately work, wait ~90 seconds and hit enter again)
4) Profit.
@2COlaltman][/url][/url Wow this is awesome, nice workaround! Thank you for providing this! ;)
And thank you for giving me credit, glad to be recognized on such a great forum! ;)
@2COlaltman
By golly, you're right! What a horrendously stupid bug. This begs the question: how many Apple engineers does it take to fix a dialog box which isn't appearing?
same problem here. I tried to upgrade to Yosemite from mavericks 10.9.5. The upgrade goes smoothly, and the drive in encrypted however, once i log in as any user it freezes at the user name and progress bar.
I was almost able to login as a local admin and that froze on "setting up your mac computer" after i skipped the iCloud setup.
*** Ran the suggestions of recovery mode to repair the drive.
I was able to erase my drive finally - no file vault error messages
reinstalled as a clean os Yosemite only.
Will migrate from time machine back up tonight.
out of curiosity, do you have mobile AD accounts (-mobile enable, or the Create Mobile account at login box checked)
@2COlaltman - I just wanted to say thank you for the information you provided above. I had remembered seeing your post some weeks ago, but until a few days back had not really considered this as the cause for our Yosemite lock-ups. Turns out this is exactly what's happening, and my post located here shows how to actually reveal the dialog causing the hang condition.
https://jamfnation.jamfsoftware.com/discussion.html?id=12589#responseChild80527
I did not give you credit because when I posted this because I couldn't recall where I'd seen this information. Now that I found it again, I'll be updating my post to point folks back to this thread for credit purposes.
This bug is absolutely infuriating. I really just don't know what's going on anymore at Apple and I'm losing a lot of faith in them to deliver a good OS. We've been working with Apple enterprise support on this and have even provided snapshots of the dialog that comes up. The kicker is, even if you explicitly disable the mounting of the home share with dsconfigad by running-
dsconfigad -sharepoint disable
and
dsconfigad -useuncpath disable
and reboot, the Mac still insists on trying to mount the user's home share while off the network, so its not even respecting the setting. Ugh! Shame on Apple for such stupid bugs!
@mm2270 That setting is only for mobile account creation. You need to remove the path manually from your DSCL attr. if the account was created with the UNC path enabled.
@spraguga, yeah I understand, but I'm not seeing anything in the settings for the local cached account to remove to help get past the issue. Still trying to locate something that will actually help us. We're testing deleting the account from dscl and recreating it, and pairing it up with the existing home folder. I know that will likely work, but I was hoping we wouldn't need to do that for every affected client.
Also, Apple enterprise support engineering is saying that setting those to disabled should be stopping the dialog from coming up, so they may confused about what it does. But they are claiming it should work anyway.
@mm2270 Did you try my fix list above which is to delete this from the user's DSCL attributes:
OriginalHomeDirectory: <home_dir><url>smb://server/username</url><path>/</path></home_dir>
If they need their home folder mounted you can create a login script or Self Service offering.
Yeah, one a few of the accounts affected by this, the attribute doesn't exist to remove, but I'm still doing some tests.
We already have a separate app/script that launches at login via a LaunchAgent and does a check for the network, looks up their home share info and mounts it, or exits silently if not on the network or no home share is mapped to the account. So we don't want nor need the auto mounting behavior in 10.10, but actually getting it to stop short of removing and recreating the account is proving a little hard.
Anyway, thanks for the info. I'll keep checking. Maybe I just got unlucky on the ones I was doing some tests on.
@spraguga What is the DSCL command to remove the users home directory with DSCL, I cant figure it out for the life of me, Unless im doing something stupid lol.
@Shawn.Waller][/url Here you go...
dscl -u <adimin username> . -delete /Users/<user> OriginalHomeDirectory
Ever seen this error when trying to run the command?
Cannot open remote host, error: DSOpenDirServiceErr
So far had to restrict everyone from upgrading to Yosemite... very sporadic system failures and users are really mad with this. Just got one of the machines working with de-crypting (just started decryption, reboot and logged in right away - it continues to de-crypt at this point) the drive. Tried all possible solutions: PRAM, SMC Reset, turn off WiFi, login with connected LAN cord to our network, without the cord, without the AC power cable, tried fixing/repairing permissions and the disk.
What I am also seeing is that for users where PRAM usually helped - it no longer helps :(
We have Macs with PGP that also exhibit this behavior.
Does this only affect users that are using homedir redirection? We're suddenly seeing Yosemite upgrades freeze on first reboot after drive unlock. The boot begins and there seems to be an issue accessing the volume. We're just trying to narrow down the problem and rule potential issues in our out.
We do not do home directory redirection and have this issue.
Just thought I'd wade back in. The issue isn't about home directory redirection, per say. The issue is about "derive home directory location", regardless of whether or not that's actually where it is...
If you have this box checked in your Active Directory bindings, which can be seen as the dscl attribute listed earlier in the thread, then you have the potential of having the issue happen:
Have a look at this thread:
https://jamfnation.jamfsoftware.com/discussion.html?id=12589
