Background items added loop bug on Fusion 13

[MikeRundle]

VMware Fusion 13 keeps on adding these launch agents / daemons files on every start and deleting them on every exist

Please fix this bug it's really annoying and it seems like it happened before with older versions

https://communities.vmware.com/t5/VMware-Fusion-Discussions/2-items-added-to-LaunchDaemons-on-each-launch-deleted-on/td-p/956070

 

macOS Ventura 13.0.1

VMware Fusion Professional 13.0.0 (20802013)

[Technogeezer]

It's annoying, but I wouldn't consider it a bug.

Fusion adds its background items each time you start it and uses macOS Launch Services to start them up. Fusion also removes them when you finish with Fusion. That's so they won't get launched and consume resources when you don't need them.  It's done that for a couple of releases now, so it's not new behavior.

What is new is how Ventura reacts. Ventura changed behavior over prior versions of macOS. It now alerts you to the fact that something's being added as a background launch item. It's good for security for Ventura to let you know about this.  But now Fusion's behavior gets to be a bit annoying.

That being said, I hope that VMware can come up with a way to stop the annoyance.

 

[MikeRundle]

OK I got it now, The problem is that you can't even silence that behavior from macOS Notification settings

[Technogeezer]

Don't get me wrong.  I know it's annoying - and I see it every time I start Fusion as well. There doesn't seem to be any way for mere mortals to silence it. It's up to VMware to do so if Apple will allow it. 

[BMcGroarty]

I'd still consider it a bug. Programs should minimize configuration changes on the host OS. VMWare doesn't have to add and remove items continuously in order to achieve its current functionality. Instead, it could add a configuration check. On each launch, it can exit quickly if it isn't needed. If performance is the consideration, it can be accomplished in a few lines of shell script or with a small stub binary that doesn't load additional libraries. Either option would have an imperceptible performance impact as long as it doesn't introduce any significant sequence dependencies in the launch configuration.

[Technogeezer]

Agreed.

This reminds me of two absolutely infuriating responses I would get when reporting things like this: “It’s not a bug, it’s a feature” or “working as designed”. 

Both used to defend the indefensible: bad design or implementation decisions..

[ColoradoMarmot]

I expect that caught them off guard with Ventura - it was added late in the beta cycle.  Hopefully 13.1 will fix it.

[jcasalino]

Still happens with Fusion 13.0.1

It's definitely annoying - it would be less so if Ventura made it a sliding notification but I don't know if that can be changed either.

[ColoradoMarmot]

No, you can't hide the system security notifications.

I've gotten into the habit of 'start vm, kill notification' double click

[TomsCat]

For me with VMware Fusion the following solution helped:

1. Launch VMWare Fusion.

2. In the finder go to /Library/LaunchDaemons .

3. Open /Library/LaunchAgents in another finder window.

4. Copy the 4 files that contain the word vmware from /Library/LaunchDaemons to /Library/LaunchAgents. Your admin password will be required.

[Doc69]

Thanks, you made my day! After months of seeing the "Background Items Added" pop-up every time I launch Fusion, it's finally gone! 

[TECH198]

Thanks.  This continues to work in Fusion 13.0.1

 

What is this "Background items" for ..btw?

[shermc]

Doesn't work.  The Background Items Added continue to show.  And there are only 3 files

[Technogeezer]

You're going to have to live with it for the time being.

macOS Ventura and later report additions to both /Library/LaunchAgents and /Library/LaunchDaemons folders in order to enhance security.. Ideally Fusion should either be

• adding its entries to /Library/LaunchDaemons once so that they aren't detected as new and only generate the warning once, or
• using Apple's newer method of defining background tasks in Ventura and later that does not require backgound task items to be added to /Library/LaunchDaemons.

Unfortunately the hack to add those items to the LaunchAgents doesn't work as you found out, and doesn't fix the problem. Fusion adds files to /Library/LaunchDaemons items every time it is launched, and deletes them every time Fusion is quit. That process keeps macOS generating the warning messages continually whenever Fusion is launched.. It doesn't matter that you've hacked the LaunchAgents folder - Fusion doesn't use those entries and it doesn't keep macOS from detecting that new files have been added to LaunchDaemons. . 

[drcomrade]

The solution that actually worked for me was to down the following:

1. Quit VMWare. 

2. System Preferences --> Notifications ---.> right click on VMWare, 'reset notifications'. 

3. Double click on VMWare Fusion.app. 

4. 'Don't allow' push notifications for VMWare. 

This forces VMWare to ask for permission to send push notifications, including 'added items that can run in te background'.

Granted, it does mean othe notifications for VMWare won't come through - but this seems like a reasonabel tradeoff. 

 

 

[Technogeezer]

---

 wrote:

The solution that actually worked for me was to down the following:

1. Quit VMWare. 

2. System Preferences --> Notifications ---.> right click on VMWare, 'reset notifications'. 

3. Double click on VMWare Fusion.app. 

4. 'Don't allow' push notifications for VMWare. 

This forces VMWare to ask for permission to send push notifications, including 'added items that can run in te background'.

Granted, it does mean othe notifications for VMWare won't come through - but this seems like a reasonabel tradeoff. 

---

I just tried it. It doesn't work. You'll get fooled into thinking it works if you quit then immediately re-launch Fusion. 

Even without turning off Notifications for Fusion, if you shut it down and then immediately re-launch Fusion you will not see the message. If you shut down Fusion, wait a few minutes, and then re-launch it, the message does reappear. 

Im almost 100% certain that it's macOS is throwing the notification, and not Fusion. macOS is doing what it's supposed to - warn you about anything putting background tasks/services in the systemwide folders. The warning is for security notification purposes, and that's not something you want suppressed.  And I believe there is some kind of timed check that macOS is doing on the LaunchDaemons and LaunchAgents folders in order to generate the notification. 

VMware aggravates the notification proliferation by constantly adding and removing its background items to the system locations every time you start and stop Fusion. No other application I know of does that - they install them once. It is a design decision by VMware (a poor one IMO) that needs to be revisited in the light of macOS's new behaviors. It's up to VMware to change Fusion to fix the issue - probably best to use Apple's recommendations on how to manage background tasks. 

[ColoradoMarmot]

Correct, this is MacOS and there's no easy to way to suppress it.  It's a design defect and an annoyance that Fusion needs to fix.

[Technogeezer]

---

 wrote:

Correct, this is MacOS and there's no easy to way to suppress it.  It's a design defect and an annoyance that Fusion needs to fix.

---

--- before Apple decides to lock down the ability of applications to add things to /Library/LaunchDaemons and /Library/LaunchAgents, which looks like the direction that they're heading. 

[drcomrade]

You are absolutely right. I was fooled. I counted my chickens before they hatched. 

[TECH198]

One thing triggers the other...  Is there any reason for VMWare to keep adding/removing these?  That is what triggers the Background notification from Apple...

Solution:  developer, don't remove them.. there is no need to remove files added to these folders.. Its seems Apple is alerting people in the right way, but the implementation of is it allowing developers to annoy users. BTW: VPN apps do the same thing. ExpressVPN is annoying me equally as bad.

But it  the way Apple allowed this add/remove to happen when there is no resewn to remove files. They introduced the issue. If users want to remove files they can  manually browse these two folders  and remove manually..

[Technogeezer]

I agree with you that VMware should not be constantly adding and removing these. It’s lazy coding - otherwise they’d have to write a proper uninstaller to remove these as opposed to just dragging the app to the trash. VMware should have installed those items once and left them there, updating them only when needed by upgrades. It’s also not like those services are started  by the system automatically  they are started on demand by Fusion  

I believe Apple is on the path of stopping the system wide Library folders from being modified by applications.

Whats annoying is that VMware knew about this long before Fusion 13.5 was released. I personally had an exchange with their staff during the Tech Preview stage. They decided not to do anything about this despite knowing about it for months. 

[mattieb]

Sorry, this doesn't actually work. It breaks networking.

I had another workaround that I've tested lightly today and have been having good luck with it so far.

The problem is that Fusion keeps adding plists to /Library/LaunchDaemons, and removing them on exit. You can see this behavior by opening this directory in the Finder.

There's a command, chflags, that comes from BSD Unix and appears to block Fusion from removing these files when it exits. All else seems to operate normally.

After starting Fusion:

cd /Library/LaunchDaemons
sudo chflags schg com.vmware.*.plist

Once this is done, Fusion should no longer remove the plist files and it doesn't seem to have a problem with the plist files remaining present. I've yet to reboot, but so far, so good.

[Technogeezer]

That's an interesting approach to working around the "problem".

But it isn't a problem that impacts the way Fusion runs; rather it's an annoyance. Fusion is working as designed (but admittedly the design is questionable or bad).

You've just introduced a potential problem for upgrading Fusion in the future. If VMware decides to change the contents of those files, you have to remember to take away the changes that you've made before upgrade. Otherwise, who knows what strange behavior is going to happen.

My recommendation is "Please don't".  Live with it and complain vehemently to VMware to fix it.

 

[mattieb]

That's fair, for sure. I'd also agree that's the right thing for most people.

Having been a Linux user for several years, I'm pretty used to living in the space between "let's get this fixed the right way" and "let's do a small thing that relieves an annoyance until it does get fixed the right way."

As it turns out, the chflags solution causes other problems, sadly. I've edited the post to reflect that.

Anyway, apologies to the folks on this thread for posting one of those things that didn't end up working anyway.

[Technogeezer]

No need for apologies. Experimentation is always a good thing, regardless of how it turns out. 

I even tried hacking the scripts that are bundled within Fusion that install and remove those plist files. My thought was
"install once if they aren't there, delete never".  This seemed to run afoul of the application signing that Apple requires. Which is normally a good thing from a security standpoint).

 

[TECH198]

To undo the lock run the following:

sudo chflags noschg com.vmware.*.plist

[Technogeezer]

---

 wrote:

To undo the lock run the following:

sudo chflags noschg com.vmware.*.plist

---

You might remember to do it. I might remember to do it. I would not be willing to wager any amount of money on how many other people would remember that they had made the change, let alone remember how to reverse it.

comments about loose nut holding the wheel and weakest link come to mind…