Unable to login with user folder on external drive since 12.5.1 upgrade

well, couldn't wait 'till tomorrow, so I just tried my aforementioned idea. These were the steps:

From the User Account on the external ssd:

• Go to… /Volumes

• rename the Folder Volume (I just added an # at the end, confirm with Admin password)

• in System Preferences, change Home Directory back to Volume (it should be set to Volume 1 at first)

You are prompted to reboot.

On reboot, directly log-in to your external User Account.

It should work, at least it did work for me. Disk Utility states Volume as Mount-Point again.

Of course Volume and Volume 1 are placeholders for your individual Volume names.

And of course, the Folder with name Volume is still there ("Go to…" Menu or Terminal look-up), but it might be safe to delete it later on. I will continue a while with the actual state and as long as nothing unexpected happens, I will most likely delete it.

Now I hope that 12.6.1 does not revive this issue.

Many thanks again to Barney-15E for that crucial hint!

Is the RAID1 array hardware of software based? macOS has been deprecating support for booting to software RAID volumes for many years so it is best to avoid software RAID except for data only drives not associated with a home user folder.

If it is a hardware RAID1 array, then it may just be an issue with the external drive not going ready in time when booting which is one of the dangers of moving the home user folder to an external drive. If you have another macOS user account on the internal boot drive, then use it to boot and log in so you can verify the external drive is mounted and accessible. Then log out and attempt to log into the macOS user account located on the external drive. If this works, then it is likely the external drive is just not going ready in time during the boot process. Otherwise, there may be a problem with the file system on the external drive or perhaps some sort of hardware issue. Try running First Aid on the external volume. Even if First Aid says everything is "Ok" click "Show Details" and scroll through the report to see if any unfixed errors are listed. If there are any unfixed errors listed, then you will need to erase the drive and restore from a backup.

Keep in mind that Apple/macOS does not like to have highly customized unexpected configurations like this as they are not tested by Apple. I've seen even simpler customizations cause recent versions of macOS to fail which were available in the GUI as standard customizations much less "advanced" options. I personally would leave the home folder on the internal boot drive and just use the external RAID1 for storing the data itself, but that is just me as I want to minimize potential issues.

Well, cannot comment on Ventura as I usually wait for at least the first or second „point update“ of a major macOS release before upgrading.

But I updated to 12.6.1 (and Safari 16.1) without issues or reversing to the „corrupted boot process to an external user account“ by using the administrative user account on the internal ssd to launch the update procedure.

It took 5 (!) automated reboots during the update process but it finished without issues.

So it might be an idea to upgrade to Ventura from an administrative user account which resides on the boot volume instead of launching the upgrade from the user account sitting on the external Volume.

It still remains unclear, what caused this login issue, but most affected users should be able to fix it with these steps:

[Note: as I’m not on an US-american OS, some parts may not be correctly named. I added an asterisk to indicate these parts but it should be clear regarding contents].

1)

Use „Go to“ Menu for „*Go to Folder…“,  type „/Volumes“ and hit „Enter“

2)

In the upcoming Finder window one will see an Alias pointing to the Macintosh HD and at least 2 more Volumes.

One will show a macOS „Volume icon“ (Volume Volume / VV), one will show up with a default macOS Folder icon (Folder Volume / FV).

The VV will have the name of the external Volume with an added number (i.e. VolumeXYZ_1).

The FV will show up with the expected external Volume name.

The VV will hold all the data of the external user account, while the FV will only hold some empty folders but also with an invisible User Library folder (/Volumes/FV name/Library).

3)

Rename the FV, i.e. by adding an „#“ at the end.

Then rename the VV to the original name by removing the numbering.

4)

Open System Preferences > *Users and Groups.

Unlock and right-click/contextual click on the external user account in the users list on the left side to open *extended options…

5)

Under *User Folder, set the user folder location to your actual path (manually or by using the *Choose… Button.

6)

Close everything and reboot.

Your now should be able to boot directly into the user account which resides on the external Volume.

As Tom Ritch pointed out, it might be a good idea to hold the FV for a while just in case you find out later, that some applications did write preferences or settings into the User Library on that Volume.

In this case it might be possible to grab the files in question to have them replace the ones in the User Library on the VV.

Otherwise one might feel compelled to set up individual applications preferences again here and there.

(At the end the FV can be deleted sometimes).

And of course do not forget to backup before updating/upgrading an OS.

cheers

Updated to 12.6.2 (including Safari 16.2) using the Admin Account on the relocated volume and had the same issue. On logging in after the update I found myself in a new user space. I checked /Volumes as suggested by Barney and found a folder alias with the same name as the Volume to which my user space has been relocated. I logged out, then back in to a user account located on the System disk. From that account I opened /Volumes and deleted the folder alias. After that I could log in to my relocated user account as expected. This confirms that the problem of aliases being created in place of volumes still exists, and that the workaround to delete the alias also still works.

I did not try to gather much information on this problem. I just wanted to confirm that the problem exists and solution works. I did look at Advanced Options in Users & Groups to confirm that the path to my relocated User Space is correct. It is; no spaces or numbers appended to any parts of any paths. While there I noticed an entry in Aliases. I do not know what this means, but I copy it here in case someone else can find some meaning:

com.apple.idms.appleid.prd.001211-05-d6bb1f24-f452-4ad5-83e4-c57c8c31a3cb

Encountering the same problem here since 12.5.1. In my judging, some security changes within the update leaded to this behaviour. (As HWTech points out, it might be a change within the boot process and the timing of when an external volume is mounted).

My workaround so far is to log into a "fall back" administrative account on the internal ssd, then directly log off again and switch to my "normal" user account on the external ssd. A bit irksome, but it works.

I'm actually undecided whether to wait for an upcoming fix or trying to change the setup to one which uses a home folder on the internal ssd but relies on Symbolic Links for all the user content (usr-Library, Applications, Documents, aso).

According to my readings so far, this solution seems generally more robust than shifting a whole user folder to an external volume.

raederlandree wrote:

... My backup admin account is setup on the internal drive. It is used for nothing but maintenance. I decided to perform the update using the backup admin account and bada bing it worked. I am able to login into my external user account with no need to change or delete any of suggestions in the prior solution. ...

and I wrote

Updated to 12.6.2 (including Safari 16.2) using the Admin Account on the relocated volume and had the same issue. ...

Together these comments suggest the problem arises when the system is updated using an externally located account. If true, this suggests

• The problem can be avoided by running system updates only from a user account which has not been relocated.
• Apple can impose a quick fix by restricting updates to only be allowed to run from a normally installed (not relocated) user space. If possible this restriction should be added to the update to 12.5.1 where we first encountered problems, as well as subsequent and future updates.
• Apple can probably reproduce the update bug by running updates while logged in from a relocated user space. (Determining conditions under which the bug can be reproduced can be critical for eliminating a bug.)
• Concern that relocated user spaces may no longer be supported is probably unwarranted.

This makes sense in a general sort of way. Often during updates multiple computer restarts are automatically invoked. When these restarts occur the system has been modified, but the modifications are not yet complete. It seems likely that the partially modified system software at some point does not work properly with a relocated user space. Precautions taken in updates before 12.5.1 which allowed use of relocated user spaces need to be implemented, if possible, in current updates.

Just found this. I had this problem too, with both recent updates of Monterey (12.5.1 and 12.6) but managed to resolve it, both times, in a way that survived reboots. It was a few months ago so the precise sequence of events is a wee bit vague but, in case it is of use, here's what I recall.

Like the OP I have a Mac mini (2018) with a tiny hard drive (120GB), so had moved my home folder to a USB SSD. After applying the 12.5.1 OS update, I could not log back into my account, instead getting the helpful message "You are unable to log in to the user account <my username> at this time. Logging in to the account failed because an error occurred."

Luckily I had a separate unused admin account whose home folder was on the main hard drive and was able to log in to that (after using the recovery partition tools to reset the password, as I'd forgotten it).

(If you don't have another admin account, btw, you can create one by deleting a certain file and making your Mac think it's being set up for the first time. See for instance here: https://www.lifewire.com/create-new-admin-account-for-login-issues-2259976)

As that admin, I right-clicked on my account in System Preferences to get Advanced Options and saw that the name of the hard drive in the path to the Home Directory didn't match the one listed in Terminal - it had an extra " 1" at the end, IIRC. So I changed it to match.

This time I was able to log in – but all of my stuff was gone, as the OS had created a new home folder for me, in the wrong place.

Logging in as the spare admin again I was eventually able to see, both in Terminal and Finder, that the external HD was listed twice. I think they had different icons in Finder. In Terminal, using

cd /Volumes

ls -l

I was able to see that the one with the "correct" name (no extra " 1" at the end) was listed next to today's date, and the group "_analyticsusers". Another version had an older date and the extra " 1" and had the group "admin".

After very carefully checking I had chosen the correct one, I unmounted or deleted (sorry, can't remember which, but I think it was deleting) the other. I think I may've had to use the right-click-on-the-user-account thing again as well, to change the path of my home directory back to its original version – but the nub of the issue was that the correct/original mountpoint name for the drive had been taken by the _analyticsusers group, which presumably I wasn't a member of. Getting rid of it and rebooting made everything OK again, and restored the HD to its original mount name (without " 1") – until the 12.6 OS update, when I had to do the latter steps all over again.

As I say, it was a month ago now, and I didn't document the steps at the time, so am a little sketchy on details. So please treat the above with great caution and don't delete anything if you're not sure!

If there's another update and I encounter the problem again, which I think is highly likely given Apple's disregard of any users with non-default set-ups, I'll return try to provide more details, but perhaps the above may offer a clue as to how to deal with the issue in the meanwhile.

Good luck everyone.

Does volume show up as a folder or a drive?

I have seen posts where an external drive, gets lost, and the mount point turned into a folder. subsequent remount of the drive gives it a suffix number and is the actual mount point.

Visually in Finder nothing has ever changed: the external volume still shows up as always as an external volume (even the custom icon remained intact). Also the expected „Volume“ name (without „1“) is shown.

I don't think I explained where to look. Use Go To Folder… in Finder and enter /Volumes.

Are the two volumes there? If so, Get Info on each. Does one of them show the Kind as folder?

I am in the US, the problem is here. Even though I am not so CLI-proficient, I have seen the issues reported by others above, and that allowing Onyx delete caches does not help. I have two weird observations to add.

When the issue first appeared, a new alias pointing to the disk where my user spaces are located also appeared. If my memory is correct, I saw this alias in Finder. I looked at System Preferences and saw the Home Directory path looked strange - too long, but I do not remember the details. Thinking I had found the problem, I clicked the Choose button and selected the disk. The new path looked better, but the disk had a number added:

/Volumes/Pegasus R4i 3/Users/ritch

Also, the Aliases box contained a path to Pegasus R4i. I deleted this and the alias disappeared from the Finder.

These changes made no difference. The problem continued.

The second weird observation was that my wife's user space, which is relocated to Pegasus R4i just as my user space is, still works to log in, and has the same path as always, which means without "space digit" appended to Pegasus R4i. Seeing that this path still works for her user space, I tried manually editing the path to my user space. As R.Simon has reported, that does not fix the problem. The weird thing is that path to the relocated directory that has always worked for my wife's user space still works, while what appears to be the same path to my user space now does not work.

I reported this issue including a System Diagnostic captured during a faulty log in attempt via Feedback Assistant on September 15. Now, over a week later, no recent similar reports are noted. I will add a link to this discussion to the report.

One potential variable which I have not seen mentioned is Intel or Apple processor. I have a MacPro7,1 and a MacBookPro18,2. Working in Photos on the same System Library I have seen differences in the user interface. Bugs running on Intel are not present running on Apple Silicon. Since the code has diverged for the two types of processor, the two branches should each be debugged. If the problem we are seeing only affects code running on Intel, and Apple is debugging only, or primarily, on AppleSi, as R.Simon says, we may have this problem for a while.

I have confirmed the solution described by R.Simon, with one small point to add. After removing the folders mischaracterized as Volumes, in other applications it may be necessary to restore links. For example, Mail Steward archives my old mail. The path by which Mail Steward accesses this archive had been changed to include the file which had been substituted for the Volume. This path had to be corrected by finding and linking the archive from within Mail Steward. Other applications which store a file path as a preference may need similar attention.

I filed a Feedback Assistant report to Apple describing this problem on September 15. I will add a note to that Feedback, referring Apple to this discussion for the solution.

Many thanks to R.Simon, Barney-15E and all the others who helped work through this mess.

Interesting find. I had found something similar: After the 12.5.1 update, instead of being logged into my main (external) user account -as it is usually the case after such point updates- the system booted with a "full" start up, showing the log in screen. I then logged into my usual (external administrative) user account and was presented with a default macOS Finder and the set up routine, that is usually shown after a clean System installation or on a first boot on a completely new Mac.

First impression was that the link to the external Home Folder was reset in System Preferences and macOS created a fresh Home Folder for this user on the internal ssd.

In System Preferences I’ve found the set up for the external Home Folder was still there, but it was set to a Volume „xyz 1“ (instead of just „xyz“). Correcting this to „xyz“ did not help, direct login remained faulty and in System Preferences the Home Folder path was again reset to „xyz 1“.

Disk Utility does not show this „new“ Volume on the higher levels, but if I select the (normal) Volume within the Container disk, it shows the „xyz 1“ Volume as Mount-Point. (And of course, this one also appears in Terminal).

No Onyx routine helped so far and I now recently stumbled over a thread which indicates, that Symbolic Links probably create issues at least on localised macOS versions: one user reported that the „outsourced“ folders are restored as empty new folders on the (internal) startup disk with their english names after each system boot. This started with Catalina and obviously leads to muddled data on internal and external volumes.

It is probably too optimistic to assume that Apple worked on the handling of SymLinks on localised macOS versions lately. Haven’t found informations so far whether US-versions of macOS are also affected, so it might work there as expected. (It also might work on localised systems if one uses the US-engl. file names, but that's just personal guesswork).

Probably, 12.5.1 contained some changes for APFS, who knows. And it seems we will spend some more time with this issue…