Thanks Daniel. Much appreciated. 

I see this on Windows when I try to eject my USB external drive and never worked out what caused it. But what works usually is cancelling the request, maybe 2 or 3 times and it works after that.

Thanks Jasper. I have tried that a dozen time and it still does not work. Only force quitting WSA or restarting lets me remove it. But  thanks for the tip.

What I suspect is that WSA leaves a reference to the drive open after the scan, and that makes the drive look busy. Common mistake when people access drives in a program.

Should be an easy fix if they looked for it. 

​@MajorHavoc  Following-up on my response to your other post - I would expect a running scan by SecureAnywhere to lock a mounted DMG or drive if it’s being actively scanned by our Daemon. If the inability to eject a drive or un-mount a DMG occurs with no scan running and just the real time shield functions are active, I would consider this to be outside of our expected behavior.

Do you mind sharing the MacOS and SecureAnywhere versions that are installed on your system? The version of SecureAnywhere can be located by opening the main user interface, clicking the gear next to “My Account”, and then navigating to the “About SecureAnywhere” tab. You can also private message me with those details if you prefer.

I fully agree, if a scan was active I would expect the drive to be locked in. Although I would argue that the scan should immediately stop if an eject is requested,  but maybe you are not given that system info alert?

But this is long past the end of the scan. 

I am running the latest MacOS Sonoma 14.6 (23G80), but this has been going on for several generations of MacOS.

WSA is 9.6.4.85:1727. But agin, this has been happening for quite some time  and several versions  

Happy to provide any other info you need  But I’m not allowed to give remote access due to private client info kept in this machine  

thanks for the response  

​@MajorHavoc Thanks for sharing. I’ll be back at the office tomorrow and have time to start testing this further. I’ll let you know what I learn. What you’ve described sounds to me like a potential bug; so if this is easy to replicate or we can get enough information to take action on it, I will make sure it gets documented and addressed. I cannot make any promises or guarantees at this moment regarding an ETA, but we will definitely be looking into this further as a team. Thanks for bringing it into focus.

That is all I can ask. Thank you. 

I removed the Solved from this thread and it’s great that we have some communication from ​@JDeBerry nice to meet you!

Thanks!

I’m good with the private talk on this now. I’ll post an update when I have one. Thanks Daniel. 

Just wondering who keeps marking this thread as solved? I have not given the best answer… so I unmarked it once again. ​@MajorHavoc choose another that’s best.

A quick update - our investigation so far suggests that a background scan of the removable media’s volume may be running and is incomplete at the time the ejection occurs. We are now pursuing this as a potential root cause, but as the behavior does not occur consistently, our goal is to try and find any variables that are consistent which might be a contributing factor we can evaluate in testing. I haven’t identified a specific pathway to replicate this, so any/all information is welcomed.

If anyone else is experiencing similar behaviors, I’d request they contact Support and we’ll be certain to collect all the necessary information to aid in our investigation. A huge thanks to ​@MajorHavoc  for all the information and help he’s provided thus far. I will continue to share updates as I learn more.

Just an update. I agree that large volumes may take some time to scan, but I am seeing this behavior on empty thumb drives, and small installer iso images mounted. IN all cases so far, quitting WSA and waiting 10 to 15 seconds, the drive ejects (if the “trying” is still happening..) So something else is still happening. Would love to hear from others if they see this and what they were doing when it happens. 

New Update:  This just happened: 

• I needed to do a backup on my MBP, so I SHUTDOWN WSA. The small icon in the menu bar vanished, I waited a few minutes and connected my external backup drive. 
• I ran Time Machine and 45 minutes later, it finished. 
• I tried to eject my Time Machine drive, and was told it could not be ejected because it was in use. 
• So I ran the following command to see who was still attached to the drive: 
  • $ sudo lsof | grep /Volumes/'M2 Backup'
• I got the following results: 

  • WSDaemon  74231                  root   21r      REG               1,24          24             6257257 /Volumes/M2 Backup/2025-01-19-135650.previous/Data/private/var/sntpd/state.bin

    WSDaemon  74231                  root   23r      REG               1,24          24             6257257 /Volumes/M2 Backup/2025-01-19-135650.previous/Data/private/var/sntpd/state.bin

    WSDaemon  74231                  root   26r      REG               1,24          24             6257257 /Volumes/M2 Backup/2025-01-19-135650.previous/Data/private/var/sntpd/state.bin

    WSDaemon  74231                  root   27r      REG               1,24          24             6257257 /Volumes/M2 Backup/2025-01-19-135650.previous/Data/private/var/sntpd/state.bin

Ok, so why is WSA still running a Deamon when I shut it down? That is just messed up. I updated my ticket on this issue, which was opened July 18, 2024, and still no fix or resolution to this issue.

And to add insult to injury, when one does a Shutdown of WSA, it leaves a Deamon running called “Webroot Mac Security Deamon” running in the background. It can be found in the Activity Monitor, but two things about it: 

1). You cannot quit it. It refuses to respond to a quit request.

2). You cannot Force Quit it either. If you try, not only does it come back very quickly, but it relaunces WSA and starts it running again. 
Webroot, this is called a Virus!

This is really disappointing.  I guess its time to uninstall WSA. 
​@TylerM: is there a place I can request a refund for this and Carbonite, neither of which has been working for over 6 months? 
Thanks

​@MajorHavoc Here is our refund page but it might be limited to 70 days. Beyond that you would have to reach out to support.

I’m sorry that these issues are unresolved for your mac installation. I know you’ve been a big voice here for a long time. While I know that you feel your concerns have gone unnoticed, I can assure you that I have been bringing it to the attention of our support and product managers. 

Thank you ​@TylerM. I appreciate the update and link.  You are right on the refund, I would have to fight for it because of the time frame. Would not be the first time I’ve tried to get a refund from a company that kept telling me they were fixing the issue, and then didn’t, and  then told me it was too late to get a refund. Been down this road before. I’ll just turn off auto renewal, hang around here for a Beta to see if it’s improved, and keep my fingers crossed. 
 

Cheers. 

I know as well and the Mac Client will get more help from someone you know in the Windows Beta and sorry that’s all I can say at this time. I just don’t know when but there on it as we Mods have seen and reported! We want a great Mac client for our Opentext/Webroot users!

Hey ​@MajorHavoc 

Here is a direct email address if you need it!