VMware Communities
Skeebopstop
Contributor
Contributor

VMWare 12/13 - MacOS Monterey - $HOME directory on external hard drive

Hi All,

Firstly, my VMWare Fusion setup was working fine, but to save on space, I moved my MacOS home directory off to an external hard drive (so downloads and the likes would go to it). This is also where my virtual machines reside (they did before as well when everything was working).

Ever since doing this, I cannot for the life of me get past the ".... "~/Library/Preferences/VMware Fusion" unable to create directory". 

I've verified all of the permissions, even forced recursive ownership on /Library/Preferences/VMware Fusion (without the $HOME ~) just to test. Attached are my console logs, where in the VMWare log you see lots of failed open files (but presumably it's meant to be creating those at first instance). 

I've really tried just about everything, launching it from Terminal where I can confirm the $HOME directory is correct, when I open it via digging into the Contents folder to run the binary standalone, I get this output, which maybe is a hint...

Wish I could solve this, Parallels runs fine and I'm trying not to have to switch over as I just bought Fusion 13 to discount that as source of issue as well.

Skeebs-Mac-mini:~ skeeb$ /Applications/VMware\ Fusion.app/Contents/MacOS/VMware\ Fusion ; exit;
I/O warning : failed to load external entity "/etc/vmware/hostd/proxy.xml"
2023-01-06T16:07:02.709| ServiceImpl_Opener: PID 10133
2023-01-06 16:07:03.148 VMware Fusion[10092:87837] Warning: Column selection is not supported in view-based table and outline views (<VMTableView: 0x7fe4f7875800>).
2023-01-06T16:07:22.223| ServiceImpl_Opener: PID 10310
Unexpected signal: 11.

 

Reply
0 Kudos
16 Replies
mailmichael
Contributor
Contributor

Signum 11 is a segmentation fault, which is definitely a bug in Fusion.  It could be bad handling of a configuration error you have in your setup or a problem you can do nothing about until they fix it.

If you haven't already, look at the fs type and mount options for the external disk and make sure it isn't setup as a removable device.  Here are the mount type and options for my home directory on my older, macbook pro 2014 vs macbook air 2000-m1: 

2014 macbook pro: apfs, local, journaled, nobrowse 
2020 macbook air m1: apfs, local, journaled, nobrowse, protect 

To make sure you are looking at the correct disk partition: 

cd ~ 
df . 
# look for the disk at the start and grep for it in mount replacing my entry: 
mount | grep /dev/disk3a5 

The VMWare Fusion v12 is installed on my Macbook Pro.  A couple years ago, I moved nearly everything off but left VMWare Fusion and my Linux VM.  I updated fusion too.  It was a hack job, where I may have removed contents under Library/Preferences.  My Linux VM runs and mounts hgfs, but clipboard doesn't work.  It gets a lot of the same issues of not finding files as in your log, but neither of the warnings -- even without having an /etc/vmware/hostd file. The only file it does appear to read is ~HOME/Library/Preferences/VMware\ Fusion/preferences, where your log doesn't list this file.  The differences are likely in the version of Fusion. 

I have a Mac-mini with Fusion at home, so can check out the logs when I'm back there later.

Hope this helps.  I'm just a user of VMWare, but had a recent issue so thought I'd pitch in to help. 

Reply
0 Kudos
Technogeezer
Immortal
Immortal

On my Mac mini 2020 (M1), I have my "regular" home directory moved off the boot drive onto an external drive, and am not seeing this behavior. (which I say for no other reason than "it can be done and can work"). 

How have you told macOS where the new location of your home directory is? Did you use a symlink (bad!!!) or did you modify the advanced properties of the user account to re-point the home directory to the new location (proper way)?

 

 

- Paul (Technogeezer)
Editor of the Unofficial Fusion Companion Guides
Reply
0 Kudos
ColoradoMarmot
Champion
Champion

FWIW, that's a *very* bad idea, and is likely to cause major issues next time you do an OS upgrade (as well as numerous other issues).  You're much better off leaving the home directory alone, and simply moving the contents of your documents folder to another location (not the folder itself).  You can change where downloads go inside the browser preferences.

Reply
0 Kudos
Technogeezer
Immortal
Immortal

I do agree with @ColoradoMarmot that the safest method for most users is to move subsets of the the home directory to the external drive. VMs are an obvious choice as they take up a lot of room. Downloads, Music libraries, and Photos libraries are pretty straightforward to move to external storage.

If you don't move the home directory properly then yes, it becomes a bad idea. And where you move it to counts. I have a Thunderbolt 3 external drive where I put my home directory. I don't really recommend a USB drive as I've seen some timing issues to mount the external home directory in some instances.

You also have to leave an admin account on the boot drive. Failure to do so means you have no recourse if something goes wrong and you can't log into your account.

I've never had an issue with performing macOS upgrades with this configuration. Of course, your mileage may vary, and unless you know what you're doing it can be more of a pain than a benefit.

 

- Paul (Technogeezer)
Editor of the Unofficial Fusion Companion Guides
Reply
0 Kudos
ColoradoMarmot
Champion
Champion

I've had numerous issues mounting encrypted external drives since Monterey, that's still not fixed in ventura.  It takes 30-60 seconds for them to appear (each - they run in serial, not parallel...sigh).  I've also had instability with external drives randomly disconnecting (which is actually worse after the latest ventura update)...if that happens to your home volume, it's...bad.  That colored my recommendation for sure.  Note that this is after I replaced all my previously working USB hubs with thunderbolt docks, because the USB implementation in Monterey caused a number of them to stop working.

It's easy to move most things off in piecemeal, though I have an issue with my mac mini (where we sync all our mobile devices), not having enough room to store the phone and ipad backups on the internal drive, and of course, there's no easy way to specify where the mobile backups should live.  Thought about moving the whole home directly, but ended up doing (I know, I know) a symlink just for the mobile backups folder to an external drive.  It's fragile, but works for the infrequent times we do local backups these days.

If Apple internal storage weren't so overpriced, it'd be an easier choice, but right now it's all risk tradeoffs.

Reply
0 Kudos
Skeebopstop
Contributor
Contributor

Thanks for the tip, here is how mine looks:

Skeebs-Mac-mini:~ skeeb$ cd ~
Skeebs-Mac-mini:~ skeeb$ df .
Filesystem   512-blocks      Used Available Capacity iused    ifree %iused  Mounted on
/dev/disk1s1  406251472 356656040  16212616    96% 2178326 81063080    3%   /System/Volumes/Data
Skeebs-Mac-mini:~ skeeb$ mount | grep /dev/disk1s1
/dev/disk1s1 on /System/Volumes/Data (apfs, local, journaled, nobrowse)

It feels to me, like what is happening is that "~" (since Catalina) mounts to /System/Volumes/Data, which does 'firmlink' (apparently) to the home directory, as you can see above. I feel like VMWare fusion is trying to write to /System/Volumes/Data/ or some such rather than the /Volumes/<drive>/<user> and the OS is intervening.

Skeebs-Mac-mini:~ skeeb$ cd ~
Skeebs-Mac-mini:~ skeeb$ df .
Filesystem   512-blocks      Used Available Capacity iused    ifree %iused  Mounted on
/dev/disk1s1  406251472 356671616  16197040    96% 2178366 80985200    3%   /System/Volumes/Data
Skeebs-Mac-mini:~ skeeb$ pwd
/Volumes/force/Skeeb
Skeebs-Mac-mini:~ skeeb$ 

For now, I have another user, so I'm just using that user to run my VM, but it's pretty annoying to have to toggle. I appreciate some of the suggestions, but this is for work and my companies development workflow is to do loads of git repos etc.. in the "~" directory, so I absolutely need the full home directory (not just downloads) somewhere with lots of storage.

 

Reply
0 Kudos
ColoradoMarmot
Champion
Champion

Sounds like they're trying to treat MacOS like it was linux/unix (which it's not).  In any case, it's a non-standard use case, and I'd bet 99% unlikely to be included in the Fusion test suite.

Reply
0 Kudos
Skeebopstop
Contributor
Contributor

agreed, but anyway to get a VMWare dev to pay attention to this post? VMWare Fusion is after all MacOS specific software... feels like there is a bug here in that when they query "~" they aren't listening to the system for the location of $HOME rather assuming it's location is at /Users/<user>

Reply
0 Kudos
Technogeezer
Immortal
Immortal


@Skeebopstop wrote:

agreed, but anyway to get a VMWare dev to pay attention to this post? VMWare Fusion is after all MacOS specific software... feels like there is a bug here in that when they query "~" they aren't listening to the system for the location of $HOME rather assuming it's location is at /Users/<user>


This forum is a user-to-user venue. VMware developers don't regularly participate in these forums. If you want to make sure it gets to the attention of VMware developers, you unfortunately have to open a support request. And yes, that's a paid proposition (either a support contract or per-incident support) unless you have purchased a license within the last 30 days (complimentary 30 day email support comes with a license upgrade or purchase).

I'm still not certain that there's an issue with Fusion's dealing with $HOME. $HOME for a user username is  /Users/username . I'm logged in as 'localadmin' and here's what I see for my home directory:

localadmin@xxxxxx ~ % ls -al /Users
total 0
drwxr-xr-x   7 root        admin  224 Dec 13 17:24 .
drwxr-xr-x  20 root        wheel  640 Dec  2 06:37 ..
-rw-r--r--   1 root        wheel    0 Dec  2 06:37 .localized
drwxr-xr-x+ 22 localadmin  staff  704 Jan  8 23:47 localadmin # <- file system thinks the directory is in /Users
localadmin@xxxxxx ~ % echo $HOME
/Users/localadmin # <- $HOME thinks its /Users/localadmin

localadmin@xxxxxx ~ % echo ~
/Users/localadmin # <- Not surprising, since ~ expands to $HOME

localadmin@xxxxxx ~ % pwd
/Users/localadmin # < $HOME is my current working directory after opening Terminal
localadmin@xxxxxx ~ % df -k .
Filesystem   1024-blocks     Used Available Capacity iused      ifree %iused  Mounted on
/dev/disk3s5   239362496 70523460 153588112    32% 1364676 1535881120    0%   /System/Volumes/Data
# ^^^ Not surprising since the
firm linked home directory storage is really on the writable Data volume.
localadmin@xxxxxx ~ % cd ..
# Now let's move up one level to the parent directory
# Where do you think we should be?

localadmin@xxxxxx /Users % pwd
/Users
localadmin@xxxxxx /Users % ls
Shared localadmin
localadmin@Upstairs /Users % df -k .

Filesystem   1024-blocks     Used Available Capacity iused      ifree %iused  Mounted on
/dev/disk3s5   239362496 70527440 153584132    32% 1364695 1535841320    0%   /System/Volumes/Data
# You can infer from this that the /Users directory is still firmlinked to the /System/Volumes/Data volume
# OK, so the system thinks we're still in the /Users directory on the boot drive. Let's go up another level.
localadmin@xxxxxx ~ % cd ..
localadmin@Upstairs / % pwd
/
localadmin@Upstairs / % ls
Applications System Volumes cores etc opt sbin usr
Library Users bin dev home private tmp var
# Sure looks like we're now at the system root to me...

The system is telling the application that the home directory is /Users/username, and that $HOME is there.

If it's working fine for another user, then there's something different about the user where it doesn't work. 

I believe you said that you relocated the home directory for the user that's having the problem. Can you elaborate on what you did to migrate the user home directory? I've got a gut feeling that something in that process might be causing your problem.

Another question. Why are you trying to execute Fusion in that manner (/Applications/VMware Fusion.app/Contents/? I try that and get some very, very strange behaviors. Even asks me to about macOS privileges I've given it before. Starting Fusion with the "open" command as so: "open /Applications/VMware\ Fusion.app" opens Fusion as I expect it should.

 

- Paul (Technogeezer)
Editor of the Unofficial Fusion Companion Guides
Reply
0 Kudos
Skeebopstop
Contributor
Contributor

The other user doesn't have it's home directory on an external drive :).  I just made another user so I could run the VM, but I don't do anything with that user other than run the VM, so it's very annoying to always have to switch users to play around with my VM.

Sounds like I'll just have to live with this issue, as I don't pay for support license, just the base software. Just an annoyance. 

Parallels runs fine with home directory on external drive, so VMWare is stuffing something up in this scenario. Hopefully they tune in. Otherwise I guess it's a rare case for some people.

Reply
0 Kudos
Technogeezer
Immortal
Immortal

I took a closer look at your earlier post where you posted this:

Skeebs-Mac-mini:~ skeeb$ cd ~
Skeebs-Mac-mini:~ skeeb$ df .
Filesystem   512-blocks      Used Available Capacity iused    ifree %iused  Mounted on
/dev/disk1s1  406251472 356671616  16197040    96% 2178366 80985200    3%   /System/Volumes/Data
Skeebs-Mac-mini:~ skeeb$ pwd
/Volumes/force/Skeeb
Skeebs-Mac-mini:~ skeeb$ 

If you moved the the home directory of user skeeb to /Volumes/force/Skeeb, (which is indicating to me that the directory should be on an external disk named 'force',  then why does a 'pwd' say "/Volumes/force/skeeb' while the "df ." says that directory resides on the /System/Volumes/Data volume?

I also see indications from your vmware-vmfusion.log file that the VM I question is /Volumes/force 1. Are there two external drives, one named 'force' and another named 'force 1'?

There is something very, very wrong here. I suspect your home directory is not where you think it is. I've seen things like this happen when an external drive goes away and you think you're accessing a mounted drive because the path name goes through the /Volumes directory. But in reality the external drive is not mounted, and you have been reading and writing to the mount point directory which still resides on the boot drive.

Can you do the following?:

df -k
ls -al /Users
ls -al /Volumes

 

- Paul (Technogeezer)
Editor of the Unofficial Fusion Companion Guides
Reply
0 Kudos
Skeebopstop
Contributor
Contributor

I agree it feels very odd, but apparently this is what MacOS did post Catalina for the 'firmlink' mounting types where they split the system versus users into partitions. It makes it all very confusing to interpret what is going on, but I assure you, from within the MacOS system, everything works and seems perfectly normal. When you start digging under the hood, it makes absolutely no sense.

This is the very thing which I think is tripping VMWare fusion up, as they are locating the $HOME directory someway other than requesting it's location from the OS, rather likely tapping into a Linux approach, which no longer seems valid to do for MacOS as they've wrapped the default Linux FS handling into their own special flavour.

Reply
0 Kudos
Technogeezer
Immortal
Immortal

Since a new user is working, and the user that you've made changes on doesn't, the logical conclusion is that the problem is with that original user directory. You've admitted you've tried to do things to that user's home directory that are not standard operating practice. Hence there's a suspicion that what you did caused the issue, not anything Fusion did.

Let's start debugging that given the evidence you've provided. 

The evidence does not support your contention that $HOME (in your case /Volumes/force/skoob) resides on an external disk. While your "home directory" naming makes it look like you moved the home directory to a mounted volume you think is called 'force". The "df" command does not support that explanation. The likely explanation given this evidence is your files are located in a directory under the /Volumes directory and those files are still on your boot disk. I contend there is no mounted external disk on the mountpoint /Volumes/force.

In which case, you've probably borked the move of the user's home directory.

Help me prove or disprove this..

If you'd like some help on this, please start by providing information that I've asked for:

  • the df and ls commands in my last post
  • An explanation of what you did to move the home directory off of the boot disk.

You seem to be resisting providing this information that's critical to figuring out what's going on. Why?

- Paul (Technogeezer)
Editor of the Unofficial Fusion Companion Guides
Reply
0 Kudos
Skeebopstop
Contributor
Contributor

To move the home directory I did it via the 'Advanced Options' of the Users via System Preferences (the proper way to do it). 

I agree that the 'df' command is confusing, however the '/System/Volumes/Data' is also what is pointed to for users whose home directory is NOT on an external drive, it is simply how MacOS now manages the user partition via this new 'firmlinking' approach, which I admittedly cannot really make sense of exactly how it's working.

External drive $HOME user: 

Skeebs-Mac-mini:~ skeeb$ cd ~
Skeebs-Mac-mini:~ skeeb$ df .
Filesystem   512-blocks      Used Available Capacity iused    ifree %iused  Mounted on
/dev/disk1s1  406251472 360705464  12163192    97% 2185257 60815960    3%   /System/Volumes/Data
Skeebs-Mac-mini:~ skeeb$ pwd
/Volumes/force/Skeeb
Skeebs-Mac-mini:~ skeeb$ 

 Internal (default drive) $HOME user:

admin@Skeebs-Mac-mini ~ % cd ~
admin@Skeebs-Mac-mini ~ % df .
Filesystem   512-blocks      Used Available Capacity iused    ifree %iused  Mounted on
/dev/disk1s1  406251472 360728112  12140544    97% 2185345 60702720    3%   /System/Volumes/Data
admin@Skeebs-Mac-mini ~ % pwd
/Users/admin
admin@Skeebs-Mac-mini ~ % 

I find it interesting how the 'df' of both is identical, which is why I feel that Linux approach to this (which presumably is how VMWare is doing it), is no longer correct in MacOS Monterey or above, you really have to ask the MacOS system for things, not Linux hooks.

Reply
0 Kudos
ColoradoMarmot
Champion
Champion

I think you're exactly right (ironically aligns with my earlier comment about not treating MacOS as linux).

Best option on this is to buy support and raise a ticket.  But, in all honesty, I would keep expectations low for a fix.

A brute-force workaround might be to use use fast user switching between the two accounts, then remote desktop from the external account to the vm running on the internal one.

But we're talking kludge at that point.  Any change of getting a machine with a bigger internal drive?

Reply
0 Kudos
Skeebopstop
Contributor
Contributor

All good, I have 5 or so machines, it's only an issue on the one and I have a workaround. I'm not going to push the issue, but as a developer myself, it's pretty useful for VMWare to keep an eye on the community forums as well....

This kind of thing pushes more and more people towards Parallels. As mentioned, I tried Parallels on my 'external drive' user and it all runs fine. 

Tags (1)
Reply
0 Kudos