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

For the record, reinstalling macOS under Apple support supervision does not correct this issue. I don't know what cruft raederlandree cleared by doing whatever fixed the issue in their case, but it was something more than an issue with the System.

I don't think restoring well over a terabyte of my data to a reformatted disk is a viable solution. I doubt I could do that, at least not without a lot of effort.

This problem needs a real solution, Apple.

Thanks to Barney-15E’s hint, I was able to solve the problem here (see end of page 2).

After everything is back to normal for the last couple of days I finally also deleted that Volume Folder without any issues.

And if 12.6.1 revives the issue, it seems to be an easy fix.

(Btw Apple really very rarely responds to a Product Feedback. But those entries are being analysed)

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!

cannot launch with user space relocated o… - Apple Community

Same problem, same workaround. In my case the user space is relocated onto an apple-supplied spinning disk system.

Thanks to HWTech for letting me know about this thread.

I forget if it was mentioned previously, but you can leave Apple with product feedback here and hope they fix the issue (Apple will not respond to you).

Product Feedback - Apple

However, I would not hold my breath as it involves an advanced customization affecting a small number of users. Like I said previously, I highly recommend not deviating too much from macOS defaults because people risk having their system broken by a simple macOS update patch. With Monterey, it seems Apple has been causing compatibility issues with each & every update patch in one way or another even on systems with mostly default setups. Keep in mind it was several months before a macOS update fixed the issue with third party NTFS drivers which affected a lot of users (an earlier macOS update broke those third drivers -- Apple never acknowledged an issue nor hinted at preparing a fix....Apple support pointed users to the third party developers to provide a fix, while those third party developers told users to have Apple fix it --- technically it is up to the third party developers to ensure their software works with the OS).

The more complex a custom configuration, the more likely something will break so users need to be prepared to deal with these situations (finding their own fix/workaround, waiting for Apple to fix things, or finding a simpler more stable way to configure the system to achieve a similar result). However, since Apple does not communicate with users about various issues, people will remain in the dark as to whether Apple is even aware of the issue and whether a fix is even being planned or if the issue is going to be ignored. Apple products have never been about custom configurations, but simplified setups and ease of use (having the ability to customize is nice, but not something guaranteed by macOS). If you look at how macOS has evolved over the years, you can see simplification is the direction Apple has chosen.

I think @Kestrel27 has the right idea on how to fix the issue, but it is hard to provide clear precise instructions (I believe another user posted something similar earlier in the thread as well). For those of us not directly experiencing the problem, it is impossible to provide the detailed instructions even though I know basically what needs to be done. Some of the process may require the user to figure out specific details on their own like @Kestrel27 did by trial and error which can be risky if you delete the wrong item. Definitely make sure to have a good backup of your data before attempting to make any changes. Once data has been deleted from an SSD (especially after the Trash has been emptied), there is no way to recover the data from the SSD due to how SSDs work. Trying to recover deleted data from a hard drive is possible, but expensive and/or time consuming.

in macOS Ventura's discussion thread, there are over 135 ME TOO reports, for a similar problem:

SMB File Sharing not working in Ventura - Apple Community

Solution was : Turning file sharing off, Reboot, turning file sharing back on.

after an update/upgrade, security tokens/codes related to verified connection, do not get properly updated or validated in newer update/upgrade process,

so i think, thats why we are seeing this similar problems,

users need to re-verify the shared-drive or shared-resources, etc.

This is being observed for External SMB-based drives, SMB-based NAS drives, Shared-folder/volume in mac computer, Shared printer in macOS computer, etc etc.

i'm sure, much more experts with more apple proprietary tools are debugging, to find a solution.

( but, installer creator should not just create such a buggy update/upgrade installer , this is not a small mistake, all shared-drive related major folder/resource is/are untouched by update/upgrade process !! to me it appearing as, they are forcing everyone to use a better/longer security token, etc, thats harder to replace-with false stuff/attempts. )

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.

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.

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.

Have send a bug report to Apple via Product Feedback with link to this thread.

If our issue is a result of some security changes within macOS, it's probably unlikely that a fix will arrive with 12.5.2 or later.

But hopefully we get response explaining the causes.

I'm preparing to change my set up to the "Symbolic Link variant" (which I wanted to use on my next Mac anyway), but at the moment, I will continue to use the workaround for a while, at least until I've found some more background to our actual issue.

If no simpler solution arises, I'll switch to symlinks and will report back here (provided that the thread stays open).

I'm preparing to change my set up to the "Symbolic Link variant" (which I wanted to use on my next Mac anyway), but at the moment, I will continue to use the workaround for a while, at least until I've found some more background to our actual issue.

Almost all of the Library-based apps which store large numbers of large files can be set to store their libraries on another drive. Photos, Music, TV, etc. all allow you to set the location for the data. Mail is likely the only one that would take up a lot of space (attachments) that doesn't allow moving the storage.

There are some apps (GarageBand) that store templates in the Library folder, so those would still be an issue.

You can always store Documents anywhere you want.

Agreed, this is correct.

Unfortunately, I'm using several applications where bigger data sets are stored within the User Library which cannot be moved elsewhere.

Another reason for shifting a whole User's Home Folder to an external volume would be the simple fact that it is a much more sorted set up in comparison to scattering larger data blocks elsewhere.

Shifting the User Home Folder to an external ssd never caused (to me) any issues for many years.

Other data that I'm not relying up on a daily base is stored on several other external volumes.

As long as Apple demands these extra charges for internal storage, I prefer to put the same money into much more 3rd party external storage.

It's usually a carefully considered set up when a user decides to shift the Home Folder to external volumes and it is based on individual needs and working routines. It's clearly not useful for everyone, but useful for some.

Similar to a decision whether to use iCloud or not. It might be convenient, but not everyone wants to or is allowed to store personal data on cloud storage.

Nevertheless, 15.6 is on the horizon and it probably already fixes the issue. If not, symlinks would be my route.