1 2 Previous Next 20 Replies Latest reply on Oct 23, 2018 4:54 AM by ik8sqi

    Permission destruction?

    bbastion Novice

      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.

        • 1. Re: Permission destruction?
          wila Guru
          vExpertCommunity WarriorsUser Moderators


          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.




          | Author of Vimalin. The virtual machine Backup app for VMware Desktop Products
          | Vimalin : Automated backups for VMware Fusion and VMware Workstation Professional
          | More info at https://www.vimalin.com
          | Twitter @wilva
          | VMware Wiki at http://www.vi-toolkit.com
          • 2. Re: Permission destruction?
            Mikero Master
            VMware Employees

            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.



            • 3. Re: Permission destruction?
              dariusd Virtuoso
              VMware EmployeesUser Moderators

              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.





              • 4. Re: Permission destruction?
                bbastion Novice

                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.

                • 5. Re: Permission destruction?
                  johnnyla Lurker

                  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.

                  • 6. Re: Permission destruction?
                    dariusd Virtuoso
                    VMware EmployeesUser Moderators

                    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.





                    • 7. Re: Permission destruction?
                      bbastion Novice

                      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!!!!!!!!!!!!!!!!!!!!

                      • 8. Re: Permission destruction?
                        dariusd Virtuoso
                        User ModeratorsVMware Employees

                        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.





                        • 9. Re: Permission destruction?
                          kkrugler Lurker

                          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

                          • 10. Re: Permission destruction?
                            dlhotka Virtuoso

                            Were you on 8.5.8?

                            • 11. Re: Permission destruction?
                              kkrugler Lurker

                              As per the blog post, I was on 8.5.1

                              • 12. Re: Permission destruction?
                                tjr1 Lurker

                                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.

                                • 13. Re: Permission destruction?
                                  wila Guru
                                  User ModeratorsCommunity WarriorsvExpert

                                  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)




                                  | Author of Vimalin. The virtual machine Backup app for VMware Desktop Products
                                  | Vimalin : Automated backups for VMware Fusion and VMware Workstation Professional
                                  | More info at https://www.vimalin.com
                                  | Twitter @wilva
                                  | VMware Wiki at http://www.vi-toolkit.com
                                  • 14. Re: Permission destruction?
                                    tjr1 Lurker

                                    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?

                                    1 2 Previous Next