Dimitris Bastas 1 Posted July 5, 2017 Share Posted July 5, 2017 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? Link to comment Share on other sites More sharing options...
ESET Staff janoo 11 Posted July 6, 2017 ESET Staff Share Posted July 6, 2017 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 Link to comment Share on other sites More sharing options...
ESET Staff MartinK 375 Posted July 6, 2017 ESET Staff Share Posted July 6, 2017 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. Link to comment Share on other sites More sharing options...
Dimitris Bastas 1 Posted July 7, 2017 Author Share Posted July 7, 2017 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. Link to comment Share on other sites More sharing options...
ESET Staff MartinK 375 Posted July 7, 2017 ESET Staff Share Posted July 7, 2017 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. Link to comment Share on other sites More sharing options...
Recommended Posts