Problem deploying agent

[Dimitris Bastas 1]

It seems that our new ESET Remote Administrator Linux appliance cannot deploy the agent on windows 7 machines which have the SMB1 protocol disabled for security reasons.
The error I see in system logs is 'CIFS VFS: cifs_mount failed w/return code = -112'
I suppose that this has to do with the fact that windows 7 machines cannot talk SMB1 any more.
When i try to manually mount a remote windows 7 share using the parameter mount -t cifs -o vers=2.0 then the mount succeeds, but how to append this parameter to ESET remote administrator?
Is there any solution to this problem?

[janoo 11]

Hi Dimitris,

Such a workaround is not supported. For these cases we provide standalone Deployment tool.

You can read more about it here: http://help.eset.com/era_install/65/en-US/index.html?deployment_tool.htm

[MartinK 378]

22 hours ago, Dimitris Bastas said:

It seems that our new ESET Remote Administrator Linux appliance cannot deploy the agent on windows 7 machines which have the SMB1 protocol disabled for security reasons.
The error I see in system logs is 'CIFS VFS: cifs_mount failed w/return code = -112'
I suppose that this has to do with the fact that windows 7 machines cannot talk SMB1 any more.
When i try to manually mount a remote windows 7 share using the parameter mount -t cifs -o vers=2.0 then the mount succeeds, but how to append this parameter to ESET remote administrator?
Is there any solution to this problem?

You have not mentioned version of appliance nor ERA you are using, but it may be possible to edit deployment script located at:

/var/opt/eset/RemoteAdministrator/Server/Scripts/UnixWindowsNetworkRemoteInstall.sh

where you should be able to easily locate cifs mounting.

As already mentioned, this is not officially supported and it has not been tested -> there is no guarantee it will work. Also be aware that modified script will be automatically replaced during repair or upgrade of ERA. It is highly probable that SELinux context will have to be restored once you modify this file using command:

/sbin/restorecon -F -R -v /var/opt/eset/RemoteAdministrator/Server

In case you will suceed, we wil appreaciate if you could share results and required modifications, as it may help other users and developers to decide of proper solution for this issue.

[Dimitris Bastas 1]

I am running the latest version of ERA (version 6.5.31.0)
Following MartinK suggestions I changed a line in the file

/var/opt/eset/RemoteAdministrator/Server/Scripts/UnixWindowsNetworkRemoteInstall.sh

Specifically the line

LANG= mount -t cifs -o "${mount_domain_option}username=$ERA_RD_WN_USERNAME" "$remote_cifs_share" "$local_cifs_mount"

becomes

LANG= mount -t cifs -o "${mount_domain_option}username=$ERA_RD_WN_USERNAME,vers=2.0" "$remote_cifs_share" "$local_cifs_mount"

After that i run the command

/sbin/restorecon -F -R -v /var/opt/eset/RemoteAdministrator/Server

and I tried to deploy the agent to one of the Windows 7 machines.
This workaround worked for me and I wish that a change will be made to the ERA webconsole interface, so that a user can tell that a windows computer has SMB version 2, before the agent can be installed remotely.

Thank you very much for the help.

[MartinK 378]

11 hours ago, Dimitris Bastas said:

This workaround worked for me and I wish that a change will be made to the ERA webconsole interface, so that a user can tell that a windows computer has SMB version 2, before the agent can be installed remotely.

Thank you very much for the help.

Thaks for testing in your environment. It has been reported and proposed solution is to make multiple mount attempts with various parameters. This should resolve also issues in environments with disabled ntlm authentication (sec=ntlm2). We do prefer not to expose such advanced parameters to users if possible.