Monitoring of Samba (CIFS) share stops working with error: Result from smbclient not suitable

Written by Claudio Kuenzler - 0 comments

Published on March 18th 2021 - Listed in Linux Windows Monitoring Samba

---

After a SLES 15 server was upgraded to SLES 15 SP2, monitoring checks on the Samba shares stopped working. Instead of returning the current share status with free/available disk space, the plugin returned an error:

root@icinga:~# /usr/lib/nagios/plugins/check_disk_smb -H sles15sp2 -s IMPORT
Result from smbclient not suitable

To compare potential differences, another Samba server, still running on SLES 15 (without Service Pack), was used.

New SMB min protocol settings

A quick check in the rpm list showed that Samba was updated from 4.7 (SLES 15) to 4.11 (SLES 15 SP2):

ck@sles15:~> rpm -qa | grep ^samba
samba-libs-4.7.11+git.153.b36ceaf2235-4.27.1.x86_64
samba-client-4.7.11+git.153.b36ceaf2235-4.27.1.x86_64
samba-4.7.11+git.153.b36ceaf2235-4.27.1.x86_64

ck@sles15sp2:~> rpm -qa|grep ^samba
samba-client-4.11.14+git.202.344b137b75d-4.14.1.x86_64
samba-libs-python3-4.11.14+git.202.344b137b75d-4.14.1.x86_64
samba-4.11.14+git.202.344b137b75d-4.14.1.x86_64
samba-libs-4.11.14+git.202.344b137b75d-4.14.1.x86_64

But the version is not the only thing which changed. Taking a closer look at the Samba configuration (using testparm) showed one particular - and important - change.

On SLES 15 the client and server protocols are defined as the following:

sles15:~ # testparm -v | grep -i prot
        client ipc max protocol = default
        client ipc min protocol = default
        client max protocol = default
        client min protocol = CORE
        server max protocol = SMB3
        server min protocol = LANMAN1

On the SLES 15 SP2 server, the protocols are different:

sles15sp2:~ # testparm -v | grep -i prot
        client ipc max protocol = default
        client ipc min protocol = default
        client max protocol = default
        client min protocol = SMB2_02
        server max protocol = SMB3
        server min protocol = SMB2_02

With the SP2 installation, the minimum SMB protocol requirements have changed to use SMB2_02.

Which version does the client use?

As the Samba shares are checked from the monitoring server(s) using the check_smb_disk plugin, it is important to find out which version this Samba client is using.

By launching smbclient manually on the client side and keeping an eye on smbstatus on the server side, the used Samba protocol version can be identified:

root@icinga:~# smbclient //SLES15/IMPORT -U -c
WARNING: The "syslog" option is deprecated
Domain=[WORKGROUP] OS=[Windows 6.1] Server=[Samba 4.7.11-git.153.b36ceaf22354.27.1-SUSE-oS15.0-x86_64]
smb: \> 

sles15:~ # smbstatus | grep icinga
23015   nobody       nobody       icinga (ipv4:10.10.100.15:56958)  NT1               -  -
IMPORT       23015   10.166.100.15 Thu Mar 18 09:48:34 2021 CET     -            -

This means, that the monitoring server by default uses NT1 as SMB protocol.

This works fine on the SLES 15 server as the required minimum protocol there is set to LANMAN1, which is lower than NT1. But the SLES 15 SP2 server now requires a minimum version of SMB 2_02, therefore the connection fails:

root@icinga:~# smbclient //SLES15SP2/IMPORT -c
WARNING: The "syslog" option is deprecated
protocol negotiation failed: NT_STATUS_INVALID_NETWORK_RESPONSE

Change protocol version on the client side (smbclient)

To be able to connect to the SLES 15 SP2 Samba server, the SMB protocol needs to be raised on the client side. In general this could be done by setting a higher version of the "client min protocol" option in /etc/smb/smb.conf, but this would then be used for all SMB connections. In this particular situation the defaults on the monitoring server should be kept, but a higher protocol version should be used for this SLES 15 SP2 server.

This can be achieved by creating a separate config file which overwrites the defaults from smb.conf:

root@icinga:~# cat /etc/samba/SLES15SP2.conf
[global]
client min protocol = SMB2_02
client max protocol = SMB3

In this config file (/etc/samba/SLES15SP2.conf), the same protocol versions are configured as defined on Samba server side.

This specific config file can now be used with smbclient with the optional -s parameter:

root@icinga:~# smbclient -s /etc/samba/SLES15SP2.conf //SLES15SP2/IMPORT -c
Enter root's password:
smb: \>

Looking at smbstatus on the SLES 15 SP2 server reveals, that the connection indeed worked:

sles15sp2:~ # smbstatus | grep icinga
17916   nobody       nobody       icinga (ipv4:10.10.100.15:50134)  SMB3_11           -                    -
IMPORT       17916   10.166.100.15 Thu Mar 18 11:46:53 2021 CET     -            -

This time smbclient used the highest available protocol version (SMB3_11) to connect.

Tell check_disk_smb to use a different client protocol

As seen above, smbclient is able to use a specific configuration file for a connection. To make check_disk_smb support this option, I created a pull request in both nagios-plugins and monitoring-plugins projects, already back in 2016. And I wrote about this code change in an older blog post (check_disk_smb: Access denied when monitoring share on old Samba server).

Meanwhile five years have passed (!) and my code change was merged in nagios-plugins project. The additional parameter -C is available in nagios-plugins since version 2.3.0. Unfortunately the code still has not yet been merged in the monitoring-plugins project. Debian and Ubuntu packages are using monitoring-plugins as upstream source, RedHat and CentOS packages use nagios-plugins as upstream project. To be able to use the -C parameter, you should probably use the latest version from the nagios-plugins project.

The -C parameter in check_disk_smb does the same as using the -s parameter in smbclient: It loads a specific Samba configuration file for this specific Samba connection:

root@icinga:~# /usr/lib/nagios/plugins/check_disk_smb -H sles15sp2 -s IMPORT -C /etc/samba/SLES15SP2.conf
Disk ok - 1718.16G (85%) free on \\sles15sp2\IMPORT | 'IMPORT'=318563057664B;1838915763404.8;2055258794393.6;0;2163430309888

And the check works again!

Add a comment

Show form to leave a comment

Comments (newest first)

No comments yet.