Jump to content

ESET Endpoint Antivirus Error: Cannot connect to Confd: No such device or address


Recommended Posts

Posted

Hi,

I always keep my Ubuntu updated as much as possible, I can't use version 20.04 as it doesn't support my hardware, so I have to use 21.

It was all working fine till this week, but an update from Ubuntu came and now I get a segmentation fault on 8.1.4. I then noticed that 8.1.5 is the latest, I've downloaded it and now I have a different errot message:

$ sudo dpkg -i eea-8.1.5.0-ubuntu18.x86_64.deb 
(Reading database ... 272993 files and directories currently installed.)
Preparing to unpack eea-8.1.5.0-ubuntu18.x86_64.deb ...
Unpacking eea (8.1.5.0) over (8.1.4.0) ...
Setting up eea (8.1.5.0) ...
ESET Endpoint Antivirus Error: Cannot connect to Confd: No such device or address

Only reference to someone who had this error before was never answered: https://forum.eset.com/topic/27816-errors-when-installing-on-debian/

There is a similar error here (just slightly different error message): https://forum.eset.com/topic/23121-efs-715580x86_64-confd-problem/

Any ideas on how to solve this problem?

Posted (edited)

Seems I've found the reason: 8.1.4 service was started but crashing, so no lock created. Since I was installing 8.1.5 on top of it, it was trying to find the lock but couldn't so... 🙂 One crash on top of another.

Solved by removing eea before trying to install new version.

Edited by ph4ckvv3r
Posted

Ok, solved the installation problem, but not the running. 8.1.5 is crashing on Ubuntu 21.

image.thumb.png.a803c5dfb1c738d01fec3682da5fa646.png

Posted

Errors stopped like this at the end... Still problems with Confd.

 

image.thumb.png.2dbd30f1c79dde8a0f44c8860e9b3de3.png

  • Administrators
Posted

I'm afraid that the issue is caused by using an unsupported version of Ubuntu.

  • ESET Staff
Posted

Hi ph4ckvv3r,

I'm not sure about this, but it looks like permission issues to product components. As Marcos has written in previous comment, your Ubuntu version is not supported, but I am not aware of such a problem as you are describing.

Could you please try to remove EEA once again and also Remote Administrator agent? After uninstall please check if everything was correctly removed -> /opt/eset, /var/opt/eset, var/log/eset. And then try to install EEA.

Regards,

Peter K.

Posted (edited)

I'm getting this problem on a fresh Red Hat Enterprise Linux 8.5 install (Paid subscription).

I've been troubleshooting for a few hours and have created a support ticket. But I'll try the suggestions given by kurco and see how that goes.

Keep in mind that I have 2 other servers running RHEL 8.5 and are working fine (they were installed a few weeks ago).

Another observation is if I install the ESET Server Security manually rather than pushing it out via the Web PROTECT console it works fine until it updates the modules, then it crashes.

 

Edited by social
Posted

it worked after removing the agent. Then installing the ESET Server Security.

It was impossible to install with the agent installed first.

Posted (edited)

I tried installing the Management agent after installing efs. However the problem came back.

Removing the management agent again fixed the problem. But now I can't control the machine from the web console.

Edited by social
  • ESET Staff
Posted

Hi social,

I have tried to replicate it, but without any success, it's working for me. Could you please share with me some details? I have used clean virtual machine of Rhel 8.5. Are you using some special configuration there? some security policy? is selinux enabled? 

Also what version of ESS are you using? latest release 8.1.813.0? 

Regards,

Peter 

Posted

Hi Peter,

I was using 8.1.4 happily and it stopped working for no reason. So I've decided to update to 8.1.5, which then got me into the need to remove 8.1.4 and install 8.1.5 from zero, which installs it. Now the problem is that it installs but it has lots of errors. I don't think it is permissions as the service requires root to be installed and run, so... 😕

is there anything I can check here? Specific logs?

image.thumb.png.ab89c9b11f67425e645d7654d50a618d.png

  • ESET Staff
Posted

Hi ph4ckvv3r,

yes it needs root for installation, but during that it creates new unprivileged users and group. I have seen this already before, that permissions were changed and some of our services started to fail.

As you can see, many of our services are not running under root
 

user@machine:~$ ps -e -o user:20,pid,cmd | grep eset
user					pid	 cmd
-------------------------------------------------------
root                    4950 /opt/eset/eea/sbin/startd
eset-eea-logd           4951 /opt/eset/eea/lib/logd
eset-eea-wapd           4952 /opt/eset/eea/lib/wapd
eset-eea-updated        4954 /opt/eset/eea/lib/updated
root                    4956 /opt/eset/eea/lib/sysinfod
eset-eea-licensed       4957 /opt/eset/eea/lib/licensed
root                    4958 /opt/eset/eea/lib/utild
eset-eea-confd          4960 /opt/eset/eea/lib/confd
ansible                15442 /bin/sh /opt/eset/eea/lib/install_scripts/egui_autorestart.sh --gapplication-service
ansible                15496 /opt/eset/eea/lib/egui --gapplication-service
root                   15773 /opt/eset/eea/lib/execd
eset-eea-scand         18317 /opt/eset/eea/lib/scand

Our log collecting script is also gathering permissions for particular folders, if you could send me this file from logs "eea_info", I can check if everything is correct there.

Regards,

Peter

Posted (edited)

I had a look at the other two servers I have ESET installed on. The only difference is that a CIS hardening policy is applied on the machine that is having problems.

  • Current product version: 8.1.813.0
  • I'm using the CIS security policy for Red Hat Server Level 1.

Try installing a fresh copy of RHEL 8.5 with that policy applied during install (Can select it in the policy section).

It requires that /var/tmp, /tmp and /home are on their own partitions.

 

I'll install a fresh copy of RHEL 8.5 without that policy later on tonight and see if I get the same problem.

Edited by social
Posted

I can't edit, I've attached a picture of the policy I used


I'm running an install of a fresh RHEL 8.5 without this policy now. I'll install ESET and see how it goes.
 

Screenshot 2022-01-18 181254.png

Posted

I can confirm that everything works fine if i install WITHOUT the CIS policy.

  • ESET Staff
Posted

Hi,

I have checked the CIS policy you mentioned and it adds noexec flags on some mountpoints, that our product is using. Check this page noexec, maybe this workaround could help you. 

Regards,

Peter

Posted
19 hours ago, kurco said:

Hi,

I have checked the CIS policy you mentioned and it adds noexec flags on some mountpoints, that our product is using. Check this page noexec, maybe this workaround could help you. 

Regards,

Peter

Thanks, I'll give that a test shortly!

Posted
22 hours ago, kurco said:

Hi,

I have checked the CIS policy you mentioned and it adds noexec flags on some mountpoints, that our product is using. Check this page noexec, maybe this workaround could help you. 

Regards,

Peter

It didnt work unfortunately.

i’ve updated my support ticket with that information.

Posted (edited)

We managed to solve the problem.

The following folders/files were missing the read and execute bit for the public permissions.

The folders were 0750 rather than 0755

They should look like this

drwxr-xr-x. 3 root root 19 nov 26 10:13 /opt/eset/RemoteAdministrator/
drwxr-xr-x. 3 root root 4096 nov 26 10:13 /opt/eset/RemoteAdministrator/Agent/
-rwxr-xr-x. 1 root root 3800400 apr 15  2021 /opt/eset/RemoteAdministrator/Agent/ERAAgent


In my case i had to updated these:
 

sudo chmod 0755 /opt/eset/RemoteAdministrator/
sudo chmod 0755 /opt/eset/RemoteAdministrator/Agent

 

Edited by social
Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...