Jump to content

Robertos

ESET Staff
  • Posts

    39
  • Joined

  • Last visited

  • Days Won

    2

Robertos last won the day on April 11

Robertos had the most liked content!

1 Follower

About Robertos

  • Rank
    Newbie
    Newbie

Profile Information

  • Location
    Slovakia

Recent Profile Visitors

223 profile views
  1. 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.
  2. 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
  3. Losing FDA during restart of macOS is macOS bug. We did workaround in released latest 7.4 to do not trigger this macOS bug.
  4. 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 ?
  5. 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.
  6. 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.
  7. 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.
  8. 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
  9. 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.
  10. 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.
  11. Thanks for update, it's nice to hear that issue was transient and was fixed for you by upgrade of the product.
  12. 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?
  13. 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.
  14. We do not know it yet. I will inform you if find any useable workaround.
×
×
  • Create New...