---

@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?

Thanks for your reply.

This is the result of running the recommended commands, which has reset the status from drwxr-xr-x to drwxrwxrwt :

192-168-1-100:~ Tim_Day$ ls -ald /tmp /private/tmp

drwxr-xr-x  8 root  wheel  256 28 Sep 08:47 /private/tmp

lrwxr-xr-x@ 1 root  admin   11 29 Jul 21:02 /tmp -> private/tmp

192-168-1-100:~ Tim_Day$ sudo chmod 1777 /private/tmp

Password:

192-168-1-100:~ Tim_Day$ sudo chmod 1777 /private/tmp

192-168-1-100:~ Tim_Day$ ls -ald /tmp /private/tmp

drwxrwxrwt  8 root  wheel  256 28 Sep 08:47 /private/tmp

lrwxr-xr-x@ 1 root  admin   11 29 Jul 21:02 /tmp -> private/tmp

192-168-1-100:~ Tim_Day$ 

I hope now that this will not keep recurring.  It is good to have access to someone like yourself which expert knowledge of this stuff.

Re your other questions; I only used the cleaner programs after the Pipe Error in an attempt to fix an unknown problem. I did not apply any manual updates between the working and non-working events.

Also: Yes, I do have Zoom, Microsoft Office but not Chrome installed and these do make automatic updates. I am not aware of other programs with manual upgrades apart from Norton Security ver 8.8 which I occasionally use to do manual Cleanups.

Glad this worked for you.

Keep an eye on if this happens again, and note if there are any events/updates that immediately preceded the change. To date I’ve not heard of any recurrences and I hope it stays that way. 

Hi again Technogeezer- your fix for my Broken Pipe error works well, but I have had a few recurrences in recent months without any obvious causes- no new program installations or upgrades that I initiated.  I tried to open my VMFusion program today and the Broken Pipe was back.  As requested, I have noted any recent upgrade activity.

I had last used the program on 15/2/23 without any problems.  The only auto-updates are listed in System Information/Software/Installations since then were Microsoft Teams, macOS Monterey, Norton for Mac.Universal, TeamViewer, Microsoft Autoupdate and some XProtect files from Apple.  I have made a screen shot of the listing below if that helps with your analysis of the problem.

Fortunately I keep the "Fix" in an accessible place as this still seems to be happening, although only rarely. 

Are you running onyx cccleaner or anything like that?  Anything that tried to repair permissions?

Haven't used any cleaner except Norton CleanUp and only rarely. Can't think of anything which involved permissions..

My immediate suspicions would be Norton and TeamViewer. Although I'm running Norton 360 on one Intel Mac PC running Monterey with no ill effects.

Now this is weird!

I fixed the permissions and used the VMFusion window and applications OK.  Also made a backup of files used on this occasion.  We then had a brief power failure 1 hr ago, and after power come back on, the Broken Pipe message reappeared.  I checked and there had been no additional installs since I checked this morning, in fact no upgrades or new installations on today's date.  I did note that TeamViewer tends to reinstall itself after a reboot so perhaps it is something to do with that, but I guess Norton also sets itself up in the background.

Over to you for other interpretations; for the moment  I will keep adjusting permissions via Terminal.  Too hard for me.

Given the reappearance of the permission error on /private/tmp after a restart, I'd have a close look at everything third-party which runs at startup, e.g. in the various Library/LaunchAgents and Library/LaunchDaemons folders.

For reference: I have had TeamViewer (or variants such as TeamViewer Host) installed and running most of the time for many years on several computers, and I have never seen this broken pipe error in VMware Fusion, nor incorrect permissions on /private/tmp. Norton has never been near any of my Macs running VMware Fusion, so that seems a more likely suspect.

I strongly suspect Norton cleanup may be fiddling with things it shouldn't.  Would suggest avoiding running that.

That's one application that will never again darken my mac.  I had to burn a machine to bare metal to get it fully uninstalled a few years back.