View Only
Expand all | Collapse all

Permission destruction?

  • 1.  Permission destruction?

    Posted May 23, 2017 02:46 PM

    When I performed an upgrade from 8.5.6 to 8.5.7, I was asked for my password. Upon providing this, the system began to exhibit odd crashes and errors several minutes later. I found that chmod was running and changed all of my entire file system permissions to root:wheel. I was able to reset these through much work, but it appears that VMWare Fusion is having some very serious problems with this upgrade.

  • 2.  RE: Permission destruction?

    Posted May 24, 2017 09:32 AM


    That -obviously- should never happen.

    Please create a support bundle via Help -> Collect Support Information

    and contact VMware Support. (To get official support please go to: Fusion Support and open a ticket at File a Support Request )

    This is not an issue we can help you with here at the forum as most people helping out at the forum are just other users and not vmware employees.

    Your logs need to be inspected by the latter.



  • 3.  RE: Permission destruction?

    Broadcom Employee
    Posted May 24, 2017 06:49 PM

    Hm... we don't do any chmod'ding [of files we don't already own] when installing. We just need permission to install KEXT's.

    Definitely check with Support, something on your setup has gone awry.


  • 4.  RE: Permission destruction?

    Broadcom Employee
    Posted May 29, 2017 02:00 AM

    Ouch... This is very painful indeed.

    I've closely inspected Initialize VMware Fusion.tool and found a defect in its error handling which might have contributed to this problem and eventually led to us performing the errant (and quite destructive) "chown"/"chmod" operation.  The defect I've spotted could not have directly caused the errant behavior on its own -- there would have had to have been some other primary failure involving disk access (perhaps an already-corrupt filesystem, an existing permissions problem, a failing disk, or a surprise disk removal) to lead us down the defective error-handling path.

    Did you end up getting in touch with our support personnel to open a support request?  I'd be quite interested in looking at the support information bundle if one is available, since it might contain information to confirm my hypothesis as well as possibly identifying the underlying trigger for the failure.




  • 5.  RE: Permission destruction?

    Posted Jun 01, 2017 01:54 PM

    Well I gave up and did a reinstall. I had so many permission problems that I couldn't manually sort through them all. Wish there was some effing tool that would repair system wide permissions after this BS!!! And yeah, I ran Disk Warrior on this volume and it did fix some issues. But heck, even with a mildly corrupted fs (THANKS APPLE for never giving us a good file system: read HFS+ is trash!) this shouldn't have happened.

    I'm very angry right now at VMware because, like you, I was looking around and found that it was trying to chown things and I've sworn off Fusion. To me, with previous problems I've been having with Unity and so forth, Parallels is just so far ahead of VMware right now that I don't feel it's worth my time in trying to hunt down issues anymore. Fusion has been one headache after another for the past year or two.

    Hope VMware eventually get's this product back up to where it was as far as quality goes.

  • 6.  RE: Permission destruction?

    Posted Jun 01, 2017 04:58 PM

    I'd like to echo this but with a new installation of VMWare, not upgrade.

    Huge interruption and consequences for my work and project schedule.

    I need to do a fresh installation of my entire OS. Not sure if you figured it out yet. My guess is that maybe you did a recursive permission changed on a directory that had a symlink to another directory with other symlinks or one that eventually went to the root "/" directory?

    Another note, I was letting the "Initializing" phase of the installation of Fusion go to hopefully it can finish possibly fix itself. A few hours of letting it go, I started to copy my files to a networked drive. When I mounted this drive, permissions were changed on the drive too!!! This was my company's network drive.. so, there's that I have to explain and deal with too.

    Good luck with this one.

    Edit: I previously opened a thread about this same issue here: Re: Latest VMWare Fusion (release date: 2017-05-18) installation messed up file permissions on Mac OS X Sierra

    Edit 2: another poster asked for me to contact you before I reformat. I'll be reformatting in the next 2 hours or so.

  • 7.  RE: Permission destruction?

    Broadcom Employee
    Posted Jun 01, 2017 06:25 PM

    I believe we've figured out how we came to do a recursive "chown" of everything, but the pathway we've discovered could only happen as a result of a previous/existing failure on your host system.  We've now received two reports of this happening within a week of each other, each of which is catastrophic on its own, but it is of even more concern that we do not know why these previous/existing failures are now coming to the surface.

    Just to be 100% clear: There was no change to VMware Fusion which could have triggered this.  The installation process has not been modified in three years.  We do not yet know (and would really like to know) why we suddenly have two separate reports of the same catastrophe.

    There is some underlying problem on affected systems which apparently now can trigger this very specific (and very unlikely!) failure.  It really is a "should never happen" scenario which we handle incorrectly, but the evidence suggests that it is happening, which gives us great incentive to try to figure out why -- as well as to make our error handling more robust.  To explain further: During the first-run setup, if it's launched from the downloaded .dmg, VMware Fusion copies itself to /Applications on your system volume and verifies that the copy was successful.  We then need to change the permission of the contents of /Applications/VMware Fusion.app .  We attempt to change directory into /Applications/VMware Fusion.app, but in the catastrophic scenario that is unsuccessful, despite us running with administrative privilege and having successfully created the directory scarce microseconds earlier, and we fail to detect and handle that error while changing directory... we make a very reasonable effort at detecting any errors during initialization, but in this particular case our error-detection is thwarted.  It would theoretically be possible to trigger this by manually deleting VMware Fusion.app at just the wrong microsecond while the initialization script is running, but you'd have to time it perfectly and nothing suggests that this happened in the cases which have been reported here.   So... why did we fail to change directory into a directory that we had just successfully created?  That is the big question.

    To troubleshoot the underlying failure, I'd like to request some information from those of you who are affected:

    1) Which version of macOS were you running on your Mac at the time of the failure?  Had you upgraded to 10.12.5?

    2) Were you running any antivirus, antimalware or intrusion-protection software on your Mac?

    3) Was there anything unusual about your host's disk configuration?  (i.e. Was your host booting macOS from anything other than a regular internal SSD or HDD?  Was the OS installed in an unusual way?  Was your disk originally formatted with an unusual filesystem or options when you last installed macOS?)

    4) Was there anything unusual about the process you followed to install VMware Fusion?  Did you download the .dmg file and double-click on VMware Fusion.app in that, and then let it do its own installation, or did you drag the .app out to some other location and run it from there?

    5) I understand that collecting a support information bundle may be out of the question.  An archive of your /var/log/system.log* and your ~/Library/Logs/VMware Fusion/* would be super helpful though.  Please let me know if you'd like an email address or upload instructions to send logs privately.

    6) If you have not yet reformatted, can you successfully change directory to "/Applications/VMware Fusion.app/Contents/Library" and run "ls -l"?  If you installed VMware Fusion to a different location, alter the "cd" command accordingly.

    With the information above, we at least stand a chance of understanding the first failure which triggered this disaster.  We're addressing the gap in error-handling regardless, but until we understand the triggering factor, it won't be possible to run VMware Fusion on systems which share the same set of conditions.

    I truly appreciate your frustration and disappointment with us and am sorry that this has happened to you.  We'd greatly appreciate any assistance you can provide, and we'll also understand entirely if you don't wish to participate any further.




  • 8.  RE: Permission destruction?

    Posted Jun 24, 2017 09:57 PM

    Personally I did upgrade to 10.12.5. I was running betas.

    I'm curious, one thing I found is that there are no utilities that repair file system permissions right now. I tried Onyx and even that didn't seem to work. Do you know of a way to fix filesystem permissions in catastrophic events like this instead of taking the reinstall path? Honestly it would be good to have such an option regardless because it seems that general filesystem permission problems cause issues EVERYWHERE with OS X.

    I have a smaller SSD for my main system volume and a larger drive for my user volume that I map my user to.

    I double clicked the VMware Fusion.app and let it do its own installation which resulted in this EFFING nightmare.

    Does 8.5.8 fix the issue or potentiality for destruction altogether? Otherwise I'm DONE DONE DONE with VMWARE!!!!!!!!!!!!!!!!!!!!

  • 9.  RE: Permission destruction?

    Broadcom Employee
    Posted Jun 25, 2017 01:55 AM

    Fusion 8.5.8 includes a fix for the defective error-handling in Fusion.  If a similar problem is encountered in the future, Fusion might be unable to run, but it should no longer fail in this destructive manner.

    We haven't yet been able to reproduce the problem, nor do we understand what the underlying root-cause is.  So far, every user who's encountered this problem and reported back to us has reported that they were running macOS 10.12.5, and the sudden onset of this problem matches very closely with the release of the macOS 10.12.5 update, so I can't help but think that some change within macOS 10.12.5 (or possibly some antivirus/antimalware package which released an update at roughly the same time) may be the underlying root-cause, but at this stage it's impossible to say for sure.

    For repairing permissions, possibly "pkgutil --repair" could be used as a starting point.




  • 10.  RE: Permission destruction?

    Posted Sep 01, 2017 09:31 PM

    I also just ran into this same problem. And no, I don't have any anti-virus/anti-malware software installed.

    I wrote a blog post about how I fixed it - see https://ken-blog.krugler.org/2017/09/01/recovering-from-a-vmware-fusion-friendly-fire-incident/

    That didn't go into details of all the dead-end approaches I tried first, before using single-user boot mode.

    One other note...the VMWare Fusion app (actually the /Applications/VMware Fusion.app/ directory) was empty after I aborted its "fix up the system" operation.

    -- Ken

  • 11.  RE: Permission destruction?

    Posted Sep 06, 2017 08:00 PM

    Were you on 8.5.8?

  • 12.  RE: Permission destruction?

    Posted Sep 06, 2017 08:56 PM

    As per the blog post, I was on 8.5.1

  • 13.  RE: Permission destruction?

    Posted Oct 24, 2017 05:53 PM

    I believe these instructions from Apple may provide a simpler solution: Resolve issues caused by changing the permissions of items in your home folder - Apple Support . I ran into this exact issue, and following the steps under "Reset permissions" fixed it for me.

  • 14.  RE: Permission destruction?

    Posted Oct 10, 2017 07:22 AM

    This had just happened to me, in approximately the same way it happened to Ken, above:

    * Purchase new Mac.

    * Restore from Time Machine backup. OS is updated automatically at some point to 10.12.6.

    * Open VMware Fusion after a couple days.

    * "Enter your password to update some settings". OK.

    * Suffer immediate heart attack.

    After a long night wired up to the Time Capsule backup I've got the machine back. Is it safe to reinstall VMware Fusion from scratch or will it perform the same action?

    Symptoms included: Mac would boot but not run applications. Stuck in a loop asking for a password to "repair the library" which it was unable to do. Also stuck in a loop panicking that "Keychain not found". I don't think it would be possible to repair the whole machine without an in-depth forensic operation.

    I did manage to pull some system logs before I wiped it, if that's helpful to anybody. Perhaps it can save another poor soul the same trouble. Certainly, this looks like it'll be a problem where VMware is carried across in a backup, and the outcome is catastrophic. Even with recent backups (phew!) the restore time was ~9 hours.

  • 15.  RE: Permission destruction?

    Posted Oct 10, 2017 08:36 AM

    Hi tjr1,

    From what I've understood that issue was found and addressed, so make sure to download the latest version of Fusion (8.5.8 or 10.0.1)



  • 16.  RE: Permission destruction?

    Posted Oct 10, 2017 09:25 AM

    I've picked up 10.0.1.

    But restoring from a backup is very likely to come with a previous version of the software. I guess there's no way to retroactively prevent this?

  • 17.  RE: Permission destruction?

    Posted Oct 13, 2017 04:17 PM

    Another data point; I was on OSX 10.12.5, and ran VMware fusion 8.5.  It needed to upgrade and asked for my password, after which it ran the recursive chown and destroyed my system.  I have now rebuilt from scratch, and moved to High Sierra (I had to buy the VMware fusion 10 upgrade as 8.5 doesn't run on Sierra).

    This is a very nasty little bug, which cost me a lot of time and effort to resolve.  I would suggest that you make it impossible to download the version of the update which destroys peoples computers.

  • 18.  RE: Permission destruction?

    Posted Dec 02, 2017 06:52 AM

    I was running vmware vusion 6 and upgraded to Mac OS Sierra and this same thing happened, it completely hosed my installation. I wasted several hours restoring my machine from a previous backup, copying new files over, and changing permissions of the new files. After this nightmare I have decided to no longer use VMware or Windows. The one app I was using, Quicken, that required me to use Windows and VMWare fusion, I've decided to run the Mac Version from now on.

    It was a huge pain dealing with this, if not for the fact that I back up often, I would have been completely screwed. Good Riddance Vmware

    - unsatisfied customer who will not be spending any more money on VMWare products

  • 19.  RE: Permission destruction?

    Posted Dec 15, 2017 05:31 PM

    I opened VMWare Fusion for the first time in months last night just before bed, upgraded it, and fell asleep before doing anything else. This morning I opened my laptop at work and saw all the error messages from every open program on my computer complaining about permissions issues, then crashing. I'm glad I was able to find this thread, because I was worried about having been hit with ransomware for a few hours this morning. I chown'd my home directory back, but obviously this is going to cause some subtle problems down the line that I can't detect yet. The VMWare Fusion app is corrupted now, and all other apps are fine, so I'm pretty confident the upgrade was the culprit.

    High Sierra 10.13.2 beta 17C85a

    (sorry I don't know the previous version of VMWare Fusion that I was running)

    Let me know how I can help.

  • 20.  RE: Permission destruction?

    Posted Dec 16, 2017 01:32 AM

    Hi Michaelphines,

    Sad to hear that there are still people bumping into this issue.

    I don't think the old version of Fusion matters, but this should not happen anymore with a current version of VMware Fusion.

    At the least the story from VMware has been that they believe that the issue has been eradicated in current versions of Fusion.

    So the real question is what version of Fusion did you install?



  • 21.  RE: Permission destruction?

    Posted Oct 22, 2018 04:44 PM

    Ouch... for whoever is reading this, this issue is not caused just by VMWare Fusion. Today I was accessing one of our ESX servers with Safari and needed to access the console of one of the guest machines. The console popped up a VMWare-related authentication screen to install a helper app... and the same nightmare issue in this entire thread just happened to me too. By the time I realized chmod was running in the background it was too late... I’m now trying to recover the permissions.


    After trying and failing with all the methods described in this thread, this is what worked for me.

    I'm using High Sierra, and as such my drive is now using APFS. With APFS Apple, if you have Time Machine enabled, creates hourly snapshots on the local drive that can then be used to restore the system state as it was before this mess. Just reboot into recovery mode (CMD-R), and select "Restore From Time Machine Backup". As the source disk, select your local disk. You'll see a list of all your hourly snapshots. Select the one you one and when the system reboots all will be back to normal.