check_disk_smb: Access Denied when monitoring share on old Samba server

Written by Claudio Kuenzler - 0 comments

Published on January 29th 2016 - last updated on March 17th 2022 - Listed in Nagios Icinga Monitoring Linux Samba

---

During the migration of a monitoring system from Nagios 4 to Icinga 2, I wanted to add a monitoring of Samba shares of the target server (running an older Samba version on SLES10).

In the Nagios 4 setup, only a general check, whether Samba responded or not, was active. In the new monitoring setup I wanted to monitor the shares directly, by using check_disk_smb.

To my big surprise the check didn't work and showed me "Access Denied", although the nagios user was created and enabled on the target system and the password is correct:

root@icinga2:/usr/lib/nagios/plugins# ./check_disk_smb -H sambaserver -s share -u nagios -p password
Access Denied

Digging through the SMB debug log 

I enabled debug logging on the Samba server to find out what's going on. This is what I got from the logs when the plugin ran:

[2016/01/28 09:04:21, 3] smbd/oplock.c:init_oplocks(863)
  init_oplocks: initializing messages.
[2016/01/28 09:04:21, 3] smbd/oplock_linux.c:linux_init_kernel_oplocks(234)
  Linux kernel oplocks enabled
[2016/01/28 09:04:21, 3] smbd/process.c:process_smb(1083)
  Transaction 0 of length 194
[2016/01/28 09:04:21, 3] smbd/process.c:switch_message(932)
  switch message SMBnegprot (pid 32416) conn 0x0
[2016/01/28 09:04:21, 3] smbd/sec_ctx.c:set_sec_ctx(241)
  setting sec ctx (0, 0) - sec_ctx_stack_ndx = 0
[2016/01/28 09:04:21, 3] smbd/negprot.c:reply_negprot(505)
  Requested protocol [PC NETWORK PROGRAM 1.0]
[2016/01/28 09:04:21, 3] smbd/negprot.c:reply_negprot(505)
  Requested protocol [MICROSOFT NETWORKS 1.03]
[2016/01/28 09:04:21, 3] smbd/negprot.c:reply_negprot(505)
  Requested protocol [MICROSOFT NETWORKS 3.0]
[2016/01/28 09:04:21, 3] smbd/negprot.c:reply_negprot(505)
  Requested protocol [LANMAN1.0]
[2016/01/28 09:04:21, 3] smbd/negprot.c:reply_negprot(505)
  Requested protocol [LM1.2X002]
[2016/01/28 09:04:21, 3] smbd/negprot.c:reply_negprot(505)
  Requested protocol [DOS LANMAN2.1]
[2016/01/28 09:04:21, 3] smbd/negprot.c:reply_negprot(505)
  Requested protocol [LANMAN2.1]
[2016/01/28 09:04:21, 3] smbd/negprot.c:reply_negprot(505)
  Requested protocol [Samba]
[2016/01/28 09:04:21, 3] smbd/negprot.c:reply_nt1(351)
  not using SPNEGO
[2016/01/28 09:04:21, 3] smbd/negprot.c:reply_negprot(606)
  Selected protocol NT LANMAN 1.0
[2016/01/28 09:04:21, 3] smbd/process.c:process_smb(1083)
  Transaction 1 of length 150
[2016/01/28 09:04:21, 3] smbd/process.c:switch_message(932)
  switch message SMBsesssetupX (pid 32416) conn 0x0
[2016/01/28 09:04:21, 3] smbd/sec_ctx.c:set_sec_ctx(241)
  setting sec ctx (0, 0) - sec_ctx_stack_ndx = 0
[2016/01/28 09:04:21, 3] smbd/sesssetup.c:reply_sesssetup_and_X(1258)
  wct=13 flg2=0xc043
[2016/01/28 09:04:21, 3] smbd/sesssetup.c:reply_sesssetup_and_X(1404)
  Domain=[WORKGROUP]  NativeOS=[Unix] NativeLanMan=[Samba 4.1.6-Ubuntu] PrimaryDomain=[]
[2016/01/28 09:04:21, 3] smbd/sesssetup.c:reply_sesssetup_and_X(1419)
  sesssetupX:name=[WORKGROUP]\[nagios]@[icingaserver]
[2016/01/28 09:04:21, 3] smbd/sesssetup.c:check_guest_password(142)
  Got anonymous request
[2016/01/28 09:04:21, 3] auth/auth.c:check_ntlm_password(221)
  check_ntlm_password:  Checking password for unmapped user []\[]@[] with the new password interface
[2016/01/28 09:04:21, 3] auth/auth.c:check_ntlm_password(224)
  check_ntlm_password:  mapped user is: []\[]@[]
[2016/01/28 09:04:21, 3] smbd/sec_ctx.c:push_sec_ctx(208)
  push_sec_ctx(0, 0) : sec_ctx_stack_ndx = 1
[2016/01/28 09:04:21, 3] smbd/uid.c:push_conn_ctx(408)
  push_conn_ctx(0) : conn_ctx_stack_ndx = 0
[2016/01/28 09:04:21, 3] smbd/sec_ctx.c:set_sec_ctx(241)
  setting sec ctx (0, 0) - sec_ctx_stack_ndx = 1
[2016/01/28 09:04:21, 3] smbd/sec_ctx.c:pop_sec_ctx(356)
  pop_sec_ctx (0, 0) - sec_ctx_stack_ndx = 0
[2016/01/28 09:04:21, 3] smbd/sec_ctx.c:push_sec_ctx(208)
  push_sec_ctx(0, 0) : sec_ctx_stack_ndx = 1
[2016/01/28 09:04:21, 3] smbd/uid.c:push_conn_ctx(408)
  push_conn_ctx(0) : conn_ctx_stack_ndx = 0
[2016/01/28 09:04:21, 3] smbd/sec_ctx.c:set_sec_ctx(241)
  setting sec ctx (0, 0) - sec_ctx_stack_ndx = 1
[2016/01/28 09:04:21, 3] smbd/sec_ctx.c:pop_sec_ctx(356)
  pop_sec_ctx (0, 0) - sec_ctx_stack_ndx = 0
[2016/01/28 09:04:21, 3] auth/auth.c:check_ntlm_password(270)
  check_ntlm_password: guest authentication for user [] succeeded
[2016/01/28 09:04:21, 3] smbd/process.c:timeout_processing(1356)
  timeout_processing: End of file from client (client has disconnected).
[2016/01/28 09:04:21, 3] smbd/sec_ctx.c:set_sec_ctx(241)
  setting sec ctx (0, 0) - sec_ctx_stack_ndx = 0
[2016/01/28 09:04:21, 3] smbd/connection.c:yield_connection(69)
  Yielding connection to
[2016/01/28 09:04:21, 3] smbd/server.c:exit_server_common(766)
  Server exit (normal exit)

The interesting and relevant part in this case are the following lines:

[2016/01/28 09:04:21, 3] smbd/process.c:timeout_processing(1356)
  timeout_processing: End of file from client (client has disconnected).

It's the client's fault?!

Using the smbclient (background) command

check_disk_smb uses the smbclient command in the background. So I tried to use smbclient directly to see more information. And yes; smbclient shows some much needed information:

root@icinga2:~# smbclient //sambaserver/share -U nagios
Enter nagios's password:
Domain=[FTPSERVERS] OS=[Unix] Server=[Samba 3.0.36-0.13.12.1-2426-SUSE-CODE10]
Server not using user level security and no password supplied.
Server requested LANMAN password (share-level security) but 'client lanman auth = no' or 'client ntlmv2 auth = yes'
tree connect failed: NT_STATUS_ACCESS_DENIED

I verified the Samba server config on the Samba server and the security is indeed set to "security = share".

sambaserver:/etc/samba # grep security smb.conf
    security = share

After some research it turns out that this causes several problems.

One of them is that as authentication mechanism the old "lanman" protocol is used, which is considered weak.
On the client side, in this case the Icinga server on which the plugin and smbclient runs, is an up to date Ubunttu 14.04 and "client lanman auth" is by default disabled and on the same time "client ntlmv2 auth" is by default set to yes.

I could have just set these two options as needed into /etc/samba/smb.conf, but then all my other Samba share checks on other Samba servers would fail.

Luckily smbclient has an option -s/--configfile. With this option, a separate config file with different values than in smb.conf can be used. In this scenario I created a seperate file with the relevant settings especially for my target sambaserver:

root@icinga2:~# cat /tmp/smbclientconfig.cfg
[global]
client lanman auth = Yes
client ntlmv2 auth = No

Now I launch the same smbclient command as before, but additionally I use the separate config file:

root@icinga2:~# smbclient //sambaserver/share -U nagios --configfile=/tmp/smbclientconfig.cfg -d 4
lp_load_ex: refreshing parameters
Initialising global parameters
rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)
params.c:pm_process() - Processing configuration file "/tmp/smbclientconfig.cfg"
Processing section "[global]"
doing parameter client lanman auth = Yes
doing parameter client ntlmv2 auth = No
pm_process() returned Yes
added interface eth0 ip=10.10.15.40 bcast=10.10.15.255 netmask=255.255.255.0
Client started (version 4.1.6-Ubuntu).
Enter nagios's password:
Connecting to sambaserver at port 445
 session request ok
Domain=[FTPSERVERS] OS=[Unix] Server=[Samba 3.0.36-0.13.12.1-2426-SUSE-CODE10]
 session setup ok
Server not using user level security and no password supplied.
 tconx ok

As the debug output shows, the separate config file was parsed. And: The connection worked!

Adjusting check_disk_smb with additional parameter (-C configfile)

So it's possible to connect with smbclient to an older Samba server (with weird and outdated settings, I agree). But what about the Monitoring plugin?

Unfortunately check_disk_smb does not have an option to use a separate config file. But hey! I can do some Perl! :-)

I adapted the Perl code of the check_disk_smb plugin, to allow a new parameter -C/--configfile which allows to use a separate config file for smbclient:

root@icinga:/usr/lib/nagios/plugins# ./check_disk_smb.new -H sambaserver -s share -u nagios -p password -C /tmp/smbclientconfig.cfg
Disk ok - 11.95G (39%) free on \\sambaserver\share | 'share'=19374014464B;27379525222.4;30600645836.8;0;32211206144

root@icinga:/usr/lib/nagios/plugins# ./check_disk_smb.new -H sambaserver -s share -u nagios -p password --configfile /tmp/smbclientconfig.cfg
Disk ok - 11.95G (39%) free on \\sambaserver\share | 'share'=19374014464B;27379525222.4;30600645836.8;0;32211206144

Here's the diff between the original check_disk_smb and my patched version:

root@icinga:~# diff check_disk_smb check_disk_smb.new
< use vars qw($opt_P $opt_V $opt_h $opt_H $opt_s $opt_W $opt_u $opt_p $opt_w $opt_c $opt_a $verbose);
---
> use vars qw($opt_P $opt_V $opt_h $opt_H $opt_s $opt_W $opt_u $opt_p $opt_w $opt_c $opt_a $opt_C $verbose);
52c52,53
<      "a=s" => \$opt_a, "address=s" => \$opt_a);
---
>      "a=s" => \$opt_a, "address=s" => \$opt_a,
>      "C=s" => \$opt_C, "configfile=s" => \$opt_C);
89a91,94
> ($opt_C) || ($opt_C = shift @ARGV) || ($opt_C = "");
> my $configfile = $opt_C if ($opt_C);
> usage("Unable to read config file $configfile\n") if ($configfile) && (! -r $configfile);
>   
189a195
>     defined($configfile) ? ("-s", $configfile) : (),
289c295
<       -w -c [-W ] [-P ] [-a ]\n";
---
>       -w -c [-W ] [-P ] [-a ] [-C ]\n";
315d320
<       
319a325,326
> -C, --configfile=STRING
>    Path to configfile which should be used by smbclient (Defaults to smb.conf of your smb installation)

Of course I shared the changes with the two upstream projects "monitoring-plugins" and "nagios-plugins":

https://github.com/monitoring-plugins/monitoring-plugins/pull/1402
https://github.com/nagios-plugins/nagios-plugins/pull/135

Hope it'll be of use for someone else, too.

Merged in nagios-plugins

Update April 11th 2017: My Pull Request was merged into the official nagios-plugins yesterday. This means that the config file parameter will be available for everyone starting with the next nagios-plugins release. Unfortunately the pull request on monitoring-plugins is still open.

Merged in monitoring-plugins

Update March 27th 2022: The Pull Request in the monitoring-plugins project took quite a long time to be merged, but today it finally happened.

Add a comment

Show form to leave a comment

Comments (newest first)

No comments yet.