Slated

Thanks. Does the log say that the message was actually delivered, rather than just sent? Was there a bounce message? Like I said, I get other email from ESET all the time, but the password reset messages are just not there, and there's nothing in my junk folder. What are the contact details for ESET UK, assuming that's my local distributor? Thanks

Yes, it's definitely the right URL. So how do I access my account? I have a valid ESET username, password and license key, but I can't log in without a password reset, and it won't send me the link.

I logged in to My Eset for the first time in a while, and was greeted with a warning that "Password reset is required". Does this mean Eset was hacked? In any case, when I click on the "Reset password" button, no email is ever received. I know Eset is able to send me emails to that address, because I receive emails from them all the time, most recently this month I got a marketing email from them. Is Eset's password reset system broken? How can I reset my password and log in to my account if I never get a password reset email from them? Please advise.

Same here. I already have a valid license, but when I log in to my.eset.com, and click on "ESET License Manager" , I get the message: A verification of license ownership is now required A verification link will be sent to email address you used for license registration [correct email address shown] When I click on "Send verification link" the message changes to "A verification link resent", the screen dulls, and I get a sort of horizontal progress bar throbber that just keeps going forever, but no email is ever actually received (and yes I checked my spam folder, and triple checked that it's the correct email address). Any progress on fixing the activation servers?

In addition to Gentoo, this problem mainly seems to affect Ubuntu systems. In any case, the solution is simple.

Mixing two or more conflicting security models on one system is a recipe for disaster. You either need AppArmor or NOD32, not both. https://help.ubuntu.com/community/AppArmor#Disable_AppArmor_framework Also see this post, which explains why you need to change NOD32's default configuration, as it's too pervasive. My advice is that if you're running a purely Linux environment, then you should use one of the native Linux security models, not an antivirus product. The main point of running AV on Linux is as a gateway to insecure systems like Windows, or as a means of recovering them, not as an alternative to Linux security, which is already more advanced than any AV out there. Otherwise, if you have only Windows, or Linux and Windows, use antivirus.

I just got bitten by this, and some research suggests that I'm not alone, so for everyone else's benefit... The default configuration for NOD32 is to add the on-access scanner library, libesets_pac.so, to /etc/ld.so.preload. This is extremely bad practice, and actually contradicts ESET's own advice, since it replaces libc fopen() et al calls on the entire system, potentially causing havoc. That is not how the scanner is meant to be used. In my case, GNU make mysteriously stopped working. Its processes became defunct. I couldn't understand why, until I changed the parallel jobs from 5 to 1, and suddenly it worked. That wouldn't make any sense unless libc had just miraculously forgotten how to access shared memory. The final clue came when I examined various system logs, and discovered prelink complaining that my entire system was now linked to libesets_pac.so, and thus couldn't be prelinked. Imagine my surprise. The solution is simple. You need to completely remove the reference to libesets_pac.so from /etc/ld.so.preload, then reboot. No further repair is required, since the modifications introduced by libesets_pac.so were only in RAM, not on disk, and were therefore lost by rebooting. Strictly speaking, there shouldn't be anything in that file at all, unless you're a developer engaging in some pretty hackish debugging, preferably on a VM that you can restore from a snapshot in an instant, when it inevitably bricks. No regular Linux desktop, and certainly no production server, should ever be hijacking libc. Ironically I'd describe that as malware behaviour. From that point on, all the mysterious issues you've been scratching your head over, since installing NOD32, will be resolved. But that doesn't mean you've lost on-access scanning, it just means that it's (quite rightly) no longer system-wide. The only time on-access scanning actually makes sense anyway is when untrusted objects are introduced to the system from outside (i.e. downloaded or copied from removable media), since everything else was either created locally or is an immutable system component from a trusted source, all of which has already been audited by a full system scan (right?). Specifically, this means that you only need to attach libesets_pac.so to internet-facing applications and services (using wrappers), and file managers accessing removable media. Everything else can be left untouched. LD_PRELOAD=/opt/eset/esets/lib/libesets_pac.so /opt/firefox/firefox-bin HTH.

Despite NOD32's default configuration, which is very wrong and actually contradicts ESET's own stated policy, LD_PRELOAD should not be set globally, and certainly not for build processes. The libesets_pac.so on-access scanner should only be used discreetly with anything that introduces objects into the system from outside, such as a mail server or web browser. It doesn't really make any sense for trusted components that operate entirely within the confines of the system, unless the means by which those components arrived on that system cannot be accounted for, and they have subsequently never been scanned. In other words, once you've completed a full system scan, thereafter the only reason you'd need on-access scanning is when downloading anything new, or loading it from removable media, in which case you only need to attach libesets_pac.so to the processes that introduce those untrusted objects. LD_PRELOAD=/opt/eset/esets/lib/libesets_pac.so /opt/firefox/firefox-bin I recommend that you completely remove libesets_pac.so from /etc/ld.so.preload, and indeed that configuration file should be and remain completely blank, as I can't really imagine any scenario where redirecting libc calls globally would be a very healthy thing to do. Selectively attach libesets_pac.so to all internet-facing services and apps, using init scripts and wrappers, and leave the rest alone, or you could end up with an unbootable system.

ESET advises against setting LD_PRELOAD globally: The NOD32 installer for Linux needs to be changed to to reflect that policy, as it currently breaks ESET's own advice, and consequently causes a lot of problems that users find difficult to track down.

However, Gentoo users should note that NOD32's installer, along with nearly all third-party Linux application installers, has no knowledge or understanding of OpenRC, and as such it will fail to add the service to the default runlevel, although it will properly install the service in /etc/init.d. This is easily rectified with: rc-update add esets default

For the benefit of any ESET staff who might read this forum... I just wanted to say thank you for providing what is probably the only decent AV solution for Linux desktops, both in terms of detection rates and the very slick UI/UX. The next nearest competitor is Sophos, which recently and quietly dropped support for the GUI, and which has lower detection rates for both Windows and Linux malware. https://community.sophos.com/kb/en-us/122722 I'm also happy to report that, to my pleasant surprise, NOD32 installs and runs flawlessly on Gentoo, a somewhat exotic meta-distro that is not officially supported by ESET (although this is often the case with Gentoo, which also runs Steam flawlessly). My use case is that I need a flexible rescue tool in a heterogeneous home computing environment, comprising a range of hardware, operating systems and both Free and proprietary software, and for me that means a Gentoo bootable USB thumbdrive including a good AV tool, amongst other things. Sadly the only Free (as in freedom) Software tool available, ClamAV, has a detection rate as low as 15%, making it essentially useless, and most of the other proprietary AV solutions for Linux are targetted purely at enterprise users, so it seems NOD32 is the only viable solution for the Linux desktop. https://www.av-test.org/en/news/news-single-view/linux-16-security-packages-against-windows-and-linux-malware-put-to-the-test/ I'm only on day two of my thirty-day evaluation, but I expect to pay for a full license at the end of the trial period, given my experience so far. I'm also considering the Windows version to replace Avast! as my current Windows solution, and the Android version as well. I note that ESET offers a "Multi-Device" license pack that represents approximately 30% discount. Please continue to support this product. Thank you.

Presumably you can add an exception rule, as per the Windows version. hxxp://support.eset.com/kb2769

Yes, ransomware protection means protection against ransomware. Anti-ransomware protection would mean protection from anti-ransomware, i.e. something that stops you from protecting yourself against ransomware, which doesn't really make any sense.

Yes, it happens when you click on the "Partner Login" link immediately under the "Suchen" (Search) box, which takes you to https://portal.eset.de, a domain registered by IKS Service GmbH, which I presume is ESET's official Partner Programme operator in Germany. This is legitimate, but the certificate has expired. IKS should be notified immediately.