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

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.

Hi, So what's the actual step by step break down of this with Ventura., Sam asking cause some people who encounter issues with the hard drive disconnecting, update, etc will need to re read all this.

Thanks

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

coping a new user folder unto a external drive then directing it in the settings/Users and Groups/Advance etc was a snitch in Ventura...I only encountered one single problem and that was related to using pro tools plugins, it turns out some apps require libraries to be in the internal hard drive...I am not sure if this is a temporary problem.

The only other problem if at all is app cleaner can't trash any system files linked to an app your trying to un install...but it can if you switch users to the admin on the internal drive.

Other then this my 80GB of notes, 45GB of app docs etc are now on a external drive home user account working flawlessly.

I think its best to AVOID booting directly into a user home folder on external SSD, I say boot into the the computer and have the user choice screen, at least I have not seen he problems you guys mentioned and its been working flawless for me in Ventura...apart Pro Tools, app cleaner or maybe a few apps requiring full disk access....

what's cool about Ventura is that you get notifications if apps like Rogue Amoeba is installing things in the background....then you can go into settings, General, Login Items and shut it off.

Had the idea that you were referring to the "12.5.1 log-in" bug after an upgrade to macOS Ventura…

Later on, I found that Ventura obviously has some issues with TCC resulting in issues with privileges to accessing certain data or Volumes.

(But the article I read did not make clear whether it's a general issue or if this only comes up on upgraded systems aka no "clean install").

…it turns out some apps require libraries to be in the internal hard drive…

This is something that I also experienced here with Modo.app, which did not launch from the external user account, but did from the one on the boot volume. The issue was introduced by a macOS update.

I imagine 2 possible reasons for this: the app in question is programmed with a hard link to a User Library on the boot volume, does not find one and refuses to launch. Or it’s related to some app license checking routines where a set up with a Home Folder on an external volume was not considered in programming. (But it's guesswork after all).

…I say boot into the the computer and have the user choice screen…

The issue handled in this thread is that a log-in to an external User Account on system boot wasn’t possible anymore.

Neither with „automated/direct log-in“, nor via the User selection screen.

Affected users had to log-in into a User Account on the boot volume, log-off again and then log-in into their usual User Account on the external hdd/ssd.

In general, as the set-up with an external User Account is an option provided by macOS and with symlinks being a standard Unix feature, I would expect Apple to care that these features do work properly (even on non-US systems). The actual state however makes me reconsider my planned investments as I now assess the (actual and future) situation as more reliable if one keeps the Home Folders on the boot volume while storing most user data externally. (Don't expect Apple to bring internal memory upgrade prices to appropriate levels, which would make things heavily easier of course).

hi, its a very interesting subject and I think Apple will solve the issues,

So far I need to switch to the internal admin user account if I need:

-to access offline google drive docs

-work with pro tools

-delete any system files during an un install

But all these things appear to be new in Ventura, things im certain apple will solve.

Assuming you know what settings in a iPhone look like Ventura is identical

I hope my post is taken with a grain of salt, I know this thread was more about how ext user structures broke with Monterey, but just saying Ventura is much more reliable in most areas and very much worth looking into...aside these issues im reporting here.

Two more weird misfunctions I just cleaned up (I think, I hope). I can't say for certain they were produced by the same macOS malfunction. It seems similar, but different enough to warrant separate mention. I will describe them for others potential benefit, perhaps including Apple fixing the underlying problem.

My AmpliFi Alien router implements a VPN through its Teleport app on my remote devices. About the same time the login problem began the Teleport lost its ability to connect. Creating and using new connection codes, and many other guesses at possible solutions, did not help. Finally, Revoking Access for the client, then re-establishing the connection did work. However, it may be that that simple process worked because before revoking I had cleaned up things as described in this tread.

I also found I could not log in from my laptop to my desktop to transfer files. Finder windows on the laptop showed the icon of the desktop, but the directory was of them laptop! I can't say when this problem began, but in the past this connection has worked easily and well. AirDrop worked as expected. Using Barney's suggestion I examined the Volumes ion the laptop and discovered one was only an alias. I deleted that alias and restarted the MBP. Afterwards I revoked, then reestablished the Teleport access and it worked.

I have no way, nor time, to test to confirm deleting the Volumes alias was a necessary part of the solution, but that seems a fair guess. At some point a warning dialog said something about a problem with a Handoff server. I do not remember details, but this clue pointing to new technology involved with these issues may suggest more to someone more knowledgable.

Our discussion here has been about manually correcting problems caused by incorrect Volume names. What Apple needs to figure out is why and how these incorrect directory structure are created in the first place.

Updated to 12.6.1 (including Safari 16.1) using the Admin Account on the boot volume and had no issues (except that the update procedure involved 5 automated reboots [see posting above]).

Can't comment on macOS Ventura (which might be the OS version that you probably asked for) because I never upgrade to a new OS version before at least the 2nd or 3rd point update is released.

R.Simon wrote:

Updated to 12.6.1 (including Safari 16.1) using the Admin Account on the boot volume and had no issues (except that the update procedure involved 5 automated reboots [see posting above]).

Can't comment on macOS Ventura (which might be the OS version that you probably asked for) because I never upgrade to a new OS version before at least the 2nd or 3rd point update is released.

I can tell you that the changes Apple implemented in Ventura are even more towards isolating this issue, but who pulls the plug in the end is not fair..

Ok so there are strange things you should be aware of in Ventura, I did have my drive go down once and got weird messages that the user could not be logged in "AT THIS TIME"...I realised that the drive was not mounted, restarted and all went perfect but..., maybe I should share the Ventura issues so we see what's ahead.

-Plugs for pro tools audio won't load on External SSD home folder., but do so internally,

-Folders using aliases to other drives in users directory (example documents, music etc) get replaced automatically when apps launch.., for example I had a alias to the "Audio Music Apps" folder on a external drive, loaded with custom presets...well, after launching Final Cut or logic none of my custom presets would be there., I went back to look at the folder thinking it was linked to the back up drive and noticed it had no I can, I put back the alias again and upon launching logic I watched it disappear and be replaced by a fresh none alias folder with default settings., then used symbolic links and it all worked., so Symb-Links are now required for outside system directory too., in fact almost all the users home directly will require this via the terminal.

But weird things did not stop there, I returned to the internal SSD user home directory to install another plugin by SSL (solid State Logic as advise by their tech help) as it failed in the external SSD home folder., and it was successful, I don't know what this plug in is installing but its part of a bundle so I have no clue why Ventura refused to install correctly on a external SSD home folder.

But wait, even more weird stuff, I created custom audio plugin settings while int he internal SSD home user account,

they where stored in " Audio Music Apps" folder, which on my music folder is an alias to a an external HD,

But when I switched users to the external SSD the alias folder to the sale external HD with custom audio settings would be replaced...so I used symbolic links via terminal and all went well..but after returning to the internal SSD home user the custom presets I had created vanished, like as if they belonged to another user and became invisible..so I again created a Symbolic link to that same "Audio Music Apps" folder on a ext HD and it works for both internal and external users, its like I have to re link the folder...but how the settings vanished and re appeared is beyond me.

What's interesting about Ventura which I can't remember if the same in Monterey is that if you drag drop a load of files unto a folder with files which have matching names it will give you the give you the option to replace them...but if you change your mind after wards you can literally undo it and all the files will re appear..I thought I drank too much wine when I saw that one.

Anyway no trolling meant by brining up Ventura, I thought maybe you guys should get a sneak peek at what's coming.

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

Seems to be an indication that the issue is a result of an intended change within macOS.

The link is connected to your Apple-ID (had that too) and this might be an indication, that there is a connection to the Apple-ID and/or iCloud services, that causes "our issue".

It also might indicate that the times for somewhat "unconventional" macOS setups come to an end.

It would be much appreciated if Apple would comment on what happens, why it happens and what users should/could consider for future setups.

you mean to say that you created a new user account after migrating, its true that you can create multiple user accounts then link them to your iCloud account...although a mess which will result in repots of multiple devices its common that developers or techs people do this to test devices.

Your method worked but be prepared for Ventura, I know this is a monetary thread but Ventura had changes to it that totally throw all the posts here off which makes me sick to be honest...im tired of the ever changing OS just to maintain control of the accessory hardware market.

Just a note: 12.6 obviously does not fix the issue.