Oh really? I will have to give that a shot and see if it resolves the issues for our users. Thanks!

Nope. They still claim they haven't found anything in the logs we provided them and the most recent thing they asked me was to try the Ventura beta... Here's their most recent response from them a couple weeks ago:

I see there have been changes related to this in the seed of macOS 13 Ventura. While we don’t recommend installing pre-release software on production systems if you’re able to try this out on a test system we’re interested in knowing whether you can still reproduce it or not.

I might try this and upgrade the one impacted user I left in this broken state to Ventura, but with how this issue presents itself there's a chance it could be back at some point in the next few weeks. Its crazy how they're handling this issue...or maybe its normal and I just don't have enough experience with them.  ¯\\_(ツ)_/¯

Ah, the old 'we're too far down the cycle to fix it in this OS' response.

I was told at a recent Apple event by Apple that they basically move engineering staff off one OS team and on to the next as they develop them, the further along it gets the more people get moved. So by the this stage in the year I get the impression there's a full team of crack engineers working on Ventura somewhere then a couple of people sat in a corner somewhere still working on the last OS (possibly as a punishment from the HR department at Apple!?).

I wouldn't be looking at putting Ventura out until well into next year really so if they don't sort this out in Monterey that's going to be a pain, we'll just have to leave those people on Big Sur for now :/

Ian

I have had this same issue on a Mid 2015 Macbook Pro, upgrade from Catalina to Monterey (Just in Monterey support, I know, but in support).

I have wiped the Macbook and ran a fesh Monterey 12.4 install and logins fine until I re-eanbled FileVault.

Resetting the SMC or booting in Safe Mode after a boot failure (Stuck with loading bar) and restarting subsequent logins work fine for half a dozen logins and the issue the returns.

Disabling Mobile account isn't an option as of course the users do need to login offsite / off domain. :-| 

Just wanted to chime in here and say I'm running into the same problem on my 2020 MacBook Air fleet after our recent push to macOS Monterey. We have about 190 of those devices on Monterey and I've received (and verified) 3 accounts of this.

Like everyone else mentioned, it doesn't seem to fully 'hang' when it's visible to the Domain Controller, only when off-site. Boot times though are significantly different on FileVault Mobile Accounts vs. FileVault Local accounts, regardless of Domain Controller visibility.

Bootimes with filevault enabled are longer than without. 
Anyway, having a mobile account and having the mac not being able to connect to the DC on boot, you will have a boot-time increase of off very precise 60seconds until it runs in a "timeout" and completes the boot. 
I have experienced and tested this while setting up a new DC infrastructure in my company. 
The solution then was, like apple wants you to do, getting rid of the mobile accounts and dc binds and move to a SSO. In my case NoMAD. 

Hi All,

I Updated to Monterey about 2 weeks ago (Clean install), no problems until today. Macbook Pro mid 2017 Touch bar, locked up, pushed power button and have only seen these problems since.

Cannot use any keyboard except for typing remotely into a terminal window. but can't type passwords in.

Can't see menu bar at top of screen.

Can't access most menus via mouse.

Cant reboot properly (it asks for password which it lets me type but nothing happens) I've got to hold power button to shut off.

SMC & NVRAM reset don't help.

Can't change Firewall or any other settings as I can't type a password (even pressing power (finger scan) button which let's me enter the password still does nothing).

I tried to get the Oxv.. app off my lan, but it locked up trying to mount my network folders.

Can anyone please help?

Regards,

Danny

I too am having this issue in our fleet. It is a mix of different devices. The latest is a user on an iMac. Was working just fine. Updated to Monterey last week and the issue started. The only common item is macOS Monterey. I will try some of the tricks mentioned above but it seems Apple is aware and do not have a fix and that is a shame.

Hi Folks,

Well I got My machine going again after about 24 hours of pain!

It turned out (I think!) the main offender was 'Dropbox.app' trying to copy the world to my dropbox, but was failing because it was trying to copy Time Machine backups to dropbox at the time, BUT I'd NEVER ENABLED TIME MACHINE! so it was just in an endless loop I think. This app had been always asking me if I wanted to Back up This Or That to dropbox and I kept on saying 'No - Don't ask me again!' when I should have just deleted the **bleep** thing, which I now have.

Anyhow I then started to get things running again and ran Oxy...app which cleaned up a bit but found no errors.

So after a lot more cleaning up and Backing up, I'm starting to trust the machine again - scary stuff isn't it?

Cheers Folks!

Danny

It seems like this issue isn't actually going to get fixed in Monteray, and unfortunately some of the affected models (e.g. '15-inch Retina MacBook Pro (Mid 2015)' which we have a lot of) are not compatible with Ventura, so this effectively means those machines can't be upgraded beyond Big Sur for us. Big Sur will drop out of security support late next year when MacOS 14 comes out basically rendering all those end of life. The same would go for the 2016 MBP models.

Yes they will be ageing by next year anyway but in the current financial climate we are expected to make things last as long as possible so this is not a good situation to be in.

I need to test if a 2017 one works OK on Ventura if I can find a spare one somewhere.

So I went again with a Mid 2015 Macbook just over 2 weeks ago, with the latest 12.6.1. Filevault enabled and so far so good, not quite counting my chickens yet, but will update on any changes. 

Hmm, OK I thought I'd give this another go and I can confirm it's still broken on 12.6.1.

To confirm the testing environment for us which produces this is:

AD bound + filevault on + mobile accounts on + no ethernet connection (so using the cached account)

We don't own any 2016 or 2017 MBPs for me to test if this is OK in Ventura however I have set up a 2017 iMac and can confirm that is exhibits exactly the same issue on Monteray and works fine when upgraded to Ventura.

This suggests to me that this has been silently fixed in Ventura so I don't buy that Apple don't know what the issue is, unless it was somehow introduced into Monteray after that was forked in Ventura.

Either way they should be able to look at the differences in the two in order to identify the issue I just don't think they'll bother at this stage :(

We found this issue with a similar set up and what resolved it for us is in Directory Bindings in the JAMF policy uncheck "Use UNC path from Active Directory to derive network home location".  For the home drive mapping in Finder we map the users shared drive by go to server and set a favorite link and have them access this way instead of the globe icon on the dock with UNC path from Active Directory.

The way I got this to work with an existing user who was having the issue, was to uncheck "Use UNC path from Active Directory to derive network home location", delete the account and home folder for the user. Recreate the mobile account and I have restarted multiple times and have had no issue.

Just for a test I rechecked the box, deleted that same mobile account I got working and then recreated the account again. Immediately I had the issue again.  

We have tested this here and found it to be working however the additional step that @OhMyGlosh has mentioned of deleting the mobile account seems necessary, however we don't think it's necessary to remove the local home folder.

So the steps working for us are

1. untick the use UNC path option

2. delete mobile account (leave home folder)

3. re-create mobile account

you would think Apple could fix this now given that it's narrowed down to that option but I won't hold my breath!

Soooo interestingly after thinking this was affecting 2015-2017 models and Monterey we had a user this week upgrade from Big Sur to Ventura on a 2019 MBP and the exact same issue occurred. The fix also worked (turning off use UNC path and re-creating MDM account) but this seems more widespread than we thought.

I think it has to do with the UNC path trying to hit AD and map and it never is able to, it should time out and login but it does not and gets stuck.  We only had a handful of devices do this and since changing our AD bind options this appears to have went away all together for us.  I have yet to open a ticket with Apple about it as I know there stance on binding to AD (they do not recommend) but we are stuck with this option for certificates right now until infrastructure gets in line.

We've decided to just get rid of the UNC setting since it's being such a pain, as others have said people can make a shortcut to their network home if needs be.

Having done some testing is seems as though you can disable the setting and then remove the home folder properties from any mobile accounts without needing to re-create the accounts or delete anything. I think this is useful since it can be done in a policy without recalling staff or machines.

This little script may be of use to others it should achieve both things:

#!/usr/bin/env zsh

echo "disabling option"
dsconfigad -useuncpath disable
echo

for i in $(ls /Users | egrep -vi "(admin|jamfmgmt|shared|^\\.|deleted)") ; do 
   echo "clearing properties on $i"
   dscl . delete /Users/$i SMBHome
   dscl . delete /Users/$i OriginalHomeDirectory
   dscl . delete /Users/$i OriginalNFSHomeDirectory
   dscl . delete /Users/$i dsAttrTypeNative:original_smb_home
done

#!/usr/bin/env zsh

echo "disabling option"
dsconfigad -useuncpath disable
echo

for i in $(ls /Users | egrep -vi "(admin|jamfmgmt|shared|^\\.|deleted)") ; do 
   echo "clearing properties on $i"
   dscl . delete /Users/$i SMBHome
   dscl . delete /Users/$i OriginalHomeDirectory
   dscl . delete /Users/$i OriginalNFSHomeDirectory
   dscl . delete /Users/$i dsAttrTypeNative:original_smb_home
done

We have tested what is posted above and it seems to work well for us. Just want to note that others will want to modify the accounts that are ignored in the "for i" line. 

glad that was of use, it was a bit hastily cobbled together and also wasn't handling spaces in names I think this was the final version it ended up at (still hasty but it's a one time fix so doesn't need to be super pretty)