Reply to Message

---

@Tim_Day wrote:

I have been getting a recurring Broken Pipe Error message in recent months, preventing me from opening the VM Fusion virtual machine. I tried a number of the solutions on the forum without benefit, but had my office IT guys work on it for 2 days.  This occurred even after fresh installs and upgrade of both my MacOS and upgrade of VMFusion.  I am now using a Mac Desktop running Catalina ver 10.15.7 with VMFusion Ver 12.1.2 using Windows 10 as the guest system.

Ultimately the problem was found to be inability to access the /tmp folder and the effective solution, every time so far this has recurred, is to use Terminal  to recreate the /tmp/vmware-username folder and re-define ownership using chown.

If the UserName is "User_Name" then the solution is  

sudo mkdir /tmp/vmware-User_Name

sudo chown User_Name /tmp/vmware-User_Name

Check it works by      ls -dl /tmp/*. 

My question is- This is a recurring problem with a clunky fix, and several other users have had this issue judging from the online forums and combined Angst.  Is VMWare able to provide a software patch or fix in the near future to avoid this problem?  

The problem seems to be in getting the VM running, not in accessing Windows10 but exactly why I don't know.  I suspect it has something to do with automatic software updates in the MacOS but it doesn't make sense to stop those for security reasons.  Can we expect a solution from VMWare?

 

---

The effective solution is NOT to manually create the directory in /tmp. That does not fix the underlying problem. There has been a rash of this error occurring and it’s almost always been because something has changed the permissions on the /private/tmp directory (where the /tmp directory is linked to) from the defaults set at macOS installation. It doesn’t appear to be Fusion that is doing this - so it’s not a VMware problem that they have to “fix”. What is Fusion supposed to do about setting proper permissions on an operating system file that it doesn’t own and otherwise should be assuming to be properly configured. 

To see if this is your problem as well, please open the Terminal app,  issue the following commands, and post the results  

ls -ald /tmp /private/tmp

If the permissions on /private/tmp are not drwxrwxrwt with owner root and group wheel, then the permissions have been reset from their defaults and are incorrect. That’s the real problem. 

If you find the permissions are not correct, the following shell command will fix it:

sudo chmod 1777 /private/tmp

Then reissue the ls command I previously posted to verify that the change has had the desired result. You no longer have to manually create the directory in /tmp.

I’ve answered this more times than I’d like to admit lately. I’m also asking the following to see if there are any patterns:

• What updates have you applied between when this works and it doesn’t?
• Are you running any “system maintenance” or “cleaner” programs?
• Do you have any software that self-updates automatically behind the scenes (Zoom/Chrome/Microsoft Office)
• Do you have software with in-app manual upgraders?