Robertos

If you set correct exclusion to backup process you could still see that real time protection is scanning backup files because other system processes could access those files, e.g. spotlight indexer. This could be turned off by correct performance expulsions on target or may be source folders. But if you will exclude so much it is dangerous, you can backup infections too. So if such huge exclusion is used it is important to scan source backup folder[s] by custom on-demand scan with In-Depth profile before backup. This on-demand scan on source data before doing backup is good to do regardless exclusions because od-scan, especially in in-depth profile, does more strong scanning that real time protection. RTP can not do it because strong scannig is time consuming and not too much real time.

Hi, you must write complete path to process binary. It is not sufficient to use application bundle only. Wildcards are not supported. e.g. if I want to exclude Safari I should create process exclusion with process path: /Applications/Safari.app/Contents/MacOS/Safari

Losing FDA during restart of macOS is macOS bug. We did workaround in released latest 7.4 to do not trigger this macOS bug.

Losing FDA is macOS issue. We did workaround for it in ECS 7.4.1600.0 and EEA 7.4.1500.0 too. We did nothing for V6, because V6 was not affected by this issue during our compatibility testing with Sonoma. If you need EES v6 for some reason and could not upgrade to EEA, you should wait until Apple fix that issue in macOS. Just for my information, what functionalities from EES V6 are you using that prevents you to upgrade to v7.4.1500.0 ?

There is not plan to add new feature in V6 in the future. LiveGuard is planned for V7 later but it is not planned to add it into V7 in, at least, next half year.

If you did everything correctly and it still not working you should wait for release of build with fixed quarantine issue. May be you could try one more hint: problematic file is in quarantine subfolder 'root' You could move this folder outside of quarantine subfolder to another disc location, e.g. to you ~/Documents/. Move means thet root folder is deleted in original location. Next restart macoS. Then try quarantine in GUI again, it should work. This allows you to restore all files except the ones that were in root subfolder. You can return root subfolder back after we release build with quarantine fix and then you will could restore rest of you files.

I suppose you see it again with 7.4.1600.0 build. If yes, there's nothing we could do with it and you should wait until Apple release macOS fixing this issue. We are sorry, but we did everything we could do to fix this OS issue.

Two ESET developers replicated your issue with content of your quarantine. Removing '356A192B7913B04C54574D18C28D46E6395428AB.*' from root quarantine fixed the issue and quarantine started to work for both developers. Let me summarize what you should do, more deeply: upgrade product to ECS 7.4.1600.0, the latest version of v7, we tested it with this build go in Terminal to you quarantine folder cd /Library/Application Support/ESET/Security/cache/quarantine check owners and POSIX right of your quarantine subfolders and files. Check it for files in subfolders too. Correct settings is for folder is: rwxrwx--- eset-ecsm-scand eset-ecsm-daemons file is: rw------- eset-ecsm-scand eset-ecsm-daemons if you settings are different correct it by these commands for: files: sudo chown eset-ecsm-scand:eset-ecsm-daemons *.* sudo chmod 600 *.* subfolders: sudo chown eset-ecsm-scand:eset-ecsm-daemons <replace_by_subfolder_name> sudo chmod 770 <replace_by_subfolder_name> in quarantine folder fro root user delete problematic files cd root rm -Rf 356A192B7913B04C54574D18C28D46E6395428AB.* verify that problematic files are removed ls -la | grep 356A192B7913B04C54574D18C28D46E6395428AB must return nothing restart macOS you quarantine in GUI or terminal should be working

Did you restart macOS? It is required after such change.

LiveGuard is planned. What do you think by ESSP? Do you think features like firewall? Firewall is planned. It should be released at the end of Q2/2024. Other Pro features not included in AV version are not planned in next half-next year.

Chas4, if you delete these files from your quarantine: /Library/Application Support/ESET/Security/cache/quarantine/root/356A192B7913B04C54574D18C28D46E6395428AB.NDF /Library/Application Support/ESET/Security/cache/quarantine/root/356A192B7913B04C54574D18C28D46E6395428AB.NQF quarantine in the product will start to work again.

Thanks for update, it's nice to hear that issue was transient and was fixed for you by upgrade of the product.

Hello, at first, you should use latest build 6.11.616.0. It is 6.11.606.0 with macOS Sonoma support. I do not understand what settings are overwritten if you upgrade existing V6 by newer version using command line installation of PKG ? It should work, new V6 should import after upgrade settings from previous installed version. Off topic: did you consider to upgrade to version 7.4.1500.0 ? If not, why? What is the reason that block you to migrate to new version 7?

We tested 7.4.1200.0 with Sonoma 14.2 BETA and FDA lost was not fixed there. We do not know what Apple will do between BETA and public release so may be Apple will fix in public release. But we won't plan to test it again with older builds without workaround, we spent a lot of resources to find out working workaround so we would not have to fight with this problem again and again. We will test if workaround in 7.4.1600.0 is still working in released 14.2 but we will not find out if it is because of workaround or fix in macOS.

We do not know it yet. I will inform you if find any useable workaround.

We are working on quarantine fix, but next planned release for ECS is in Q2/2024. May be there will be not-planned hot fix release, but as you know it is not planned so I can not tell when it will be released or whether it will be. If in the quarantine are files required by WINE or CrossOver is not better choice for you to make new clean installation of latest versions of those product and manually delete quarantine in ECS?

Chas4, we apologies for long time of processing files you were reported to ESET. Thank you for your reports. Now, we made some improvements in false positive detections. Product should not detect file for latest installation of WINE or CrossOver as infections. It should be applied to already released builds, so 7.4.1600.0 should not detect it as well.

Would be nice to hear that work around in 7.4.1600.0 fixed lost full disk access for you. At least those who reported this issue, are you still notice this issue?

New version 7.4.1500.0 is in repository now.

Pico update is not planned for ESET Cyber Security for macOS. Machine learning is planned.

Lost full disk access is macOS Sonoma issue. Apple knows it. Anyway, we did workaround to fix it in ECS 7.4.1600.0 and it should work at least on real HW. After fix we were not able replicate this problem on real HW, but still was able to replicate it in virtual machines running Sonoma. But not all VM vendors were affected so you should test it to see if fix is working for you. Business customers: EEA 7.4.1500.0 has the same FDA fix.

Your quarantine issue is not fixed in 7.4.1600.0 yet. As I wrote you in private message: I advice you to restore file you are need and were moved to quarantine by reinstalling those application, or from valid backup and then delete quarantine content by deleting quarantine folder. macOS restart after quarantine folder deletion is required. If the product is still detecting you files and you are sure that it is false positive detections you could setup performance exclusion on those files but it lowers your security. It is on you own risk!!!, you must be sure that files you are excluding are safe.

As I wrote, mentioned file itself is not the problem. I assume that problem is in files you have in quarantine now. All detected files stored in your quarantine are real infections, except of eicar, though several from them are not harmful on macOS. If you do not need these files we recommend to delete them. If you need them and are not to able to restore it from non-infected backup you can try to rescan those files again. You should update modules to latest version, then you could restore file form quarantine and rescan it again by custom ondemanfd scan if real time protection doesn't detect it automatically. If it was false positive new scanner module could not detect it again. If it is still detected then it is infection and you should leave it in quarantine and check it again later in the future.

It was not removed, it only was not implemented yet. Unfortunately, we do not plan to implement it in the next yer, it has very low priority. What action from context menu is missing for you?

Did in-depth scan found any infections? I've tested your 1byte PDF file you send me. In-depth scan did not detect it as infection now. I added file to quarantine manually, GUI shows quarantine correctly, I could restore it from quarantine to disk too. Why do you think that this file is the problem?