Issues with NFS shares and mounting at startup - Linux clients

We have an issue with our Linux clients running Agent v8.15.x (and have had before on earlier versions as well) where every NFS share gets mounted by the elastic agent user at time of boot - for no obvious reasons. We've tried tweaking the agent configuration by black-listing file systems like nfs/nfs4 to no avail.

Is there any way we can configure the agent to prevent this from happening?

Thanks in advance // Mike

Do you have FIM (File Alteration Monitor) enabled?
My guess is FIM touches the unmounted directory which in turn causes autofs to mount the NFS mountpoint.

Can you check and try to disable autofs and see if the problem remains?

1 Like

Thanks for getting back to us quickly! Just to make sure, if you by FIM mean the Defend policy setting to scan files upon modification? If not, then if you would be so kind as to point out what parameter you're referring to? I should perhaps clarify that we're on a Basic license, if that makes any difference.

Our Linux technicians have told us that disabling automount is not an option due to potential, unforseeable consequences.

Thanks // Mike

Hi @michael-a are you refering to Elastic Agent specifically or to "the agent running on the host" for Elastic Defend integration?

The service behind Elastic Defend is called ElasticEndpoint, but it always works in tandem with Elastic Agent service.

Which integrations have you added to the policy? Can you find one causing this, by trying elimination game, assigning some host temporarily to a policy without the integration

2 Likes

Hi @lesio, thanks - you have to excuse the lack of information provided, but it's the Elastic Defend integration I mean, and besides that we use Osquery Manager and System. We have done a number of tests in regards to the Defend integration, but none have made any noticable difference - mounting still occurs on boot. We have been able to conclude that it's the Defend integration that's causing the NFS mounts though.

Thanks // Mike

Tahnks for the clarification. We don't know about such issue.

Could you upload (I'll send you the upload link via DM) the diagnostics zip to us doing the following:

  • set log level to Debug, this will make a policy change, make sure it's applied on the target machine
  • then reboot the machine
  • gather diagnostics zip
  • switch back logs so Info (debug is very noisy and will consume your stack storage)

If it's up to date stack, you can just collect the Agent diagnostic zip from Kibana, otherwise for older versions I'd appreciate collecting also the zip made by Elastic Defend (elastic endpoint service) which can be generated from the command line on the target system Elastic Endpoint command reference | Serverless | Elastic

1 Like