smbd errors after upgrading

[John M. Długosz]

After upgrading freeNAS, I now see "errors have occurred" at the top of the web screen, and the log at the bottom shows many repetitions of:

Code:

Jul  6 20:51:40 Oort smbd[79558]:  STATUS=daemon 'smbd' finished starting up and ready to serve connectionsmatchname: host name/name mismatch: 192.168.1.71 != (NULL)
Jul  6 20:51:40 Oort smbd[79558]: [2014/07/06 20:51:40.528290,  0] ../source3/lib/util_sock.c:1199(get_remote_hostname)
Jul  6 20:51:40 Oort smbd[79558]:  matchname failed on 192.168.1.71
Jul  6 20:51:40 Oort winbindd[2693]: [2014/07/06 20:51:40.828360,  0] ../source3/winbindd/winbindd_samr.c:769(sam_rids_to_names)
Jul  6 20:51:40 Oort winbindd[2693]:  sam_rids_to_names: possible deadlock - trying to lookup SID S-1-5-21-1067817215-2072143659-3874404558

I looked at the CIFS settings and don't see anything that means anything to me. Can someone help me understand this?

Thanks,
—John

 

[dlavigne]

Does changing the "Server maximum protocol" setting in Services → CIFS to "SMB2" fix it?

 

[John M. Długosz]

Does changing the "Server maximum protocol" setting in Services → CIFS to "SMB2" fix it?

Thanks for the suggestion.
I find that it's already set that way.

I find that the IP address it's complaining about, .71, is a PC that I'm using at the moment and it does access shares on that server. This is not a Domain, but a Win Workgroup, typical for SOHO LANs.

"192.168.1.71 != (NULL)", so does that mean it thinks that computer has a name rather than just an ip address, but then can't produce it?

 

[dlavigne]

Does adding that host to the "Host Name Database" field of Global Configuration fix it?

 

[John M. Długosz]

I saw a setting for use names instead of just ip addresses for blacklist/whitelist checking. I unchecked that and have not gotten any log spew in a few hours.

The hosts are all DHCP, so I couldn't just add it hard-coded to a list somewhere.

 

[jlpellet]

I am having a similar change with the upgrade to .6 - every time I connect to the share, I get the following message in /var/log/samba4/log.smbd. If I'm copying 20 files, I get it 20 times. I did not see this in the logs before. Changing CIFS to SMB2 (from SMB3) had no effect. Note I am not getting "errors" but log is filling up.

[2014/07/08 08:32:00.993835, 1] ../source3/smbd/service.c:1130(close_cnum)
desktop (ipv4:192.168.0.142:1769) closed connection to service Stores
STATUS=daemon 'smbd' finished starting up and ready to serve connectionsWARNING: The "null passwords" option is deprecated
Any ideas?

John

 

[cyberjock]

Honestly, I'd put in a bug ticket on this and see what its all about. The developers don't hang in the forums so they won't read this thread otherwise...

 

[anodos]

Did you have 'hostname lookups' enabled in your CIFs config?

 

[John M. Długosz]

I'm not getting the log spew about ip address != NULL anymore, but get this one when I access a share:

Code:

Jul  8 22:52:28 Oort winbindd[97058]: [2014/07/08 22:52:28.391666,  0] ../source3/winbindd/winbindd_samr.c:769(sam_rids_to_names)
Jul  8 22:52:28 Oort winbindd[97058]:  sam_rids_to_names: possible deadlock - trying to lookup SID S-1-5-21-1067817215-2072143659-3874404558

"Hostnames lookups" was checked, I just un-checked it and that seems to have cured that apparent problem. I don't know what it was before upgrading, but it didn't have any complaints.

 

[jlpellet]

Thanks! I change the CIFS setting to log = none vs. minimal by default & the log stopped filling up.

 

[anodos]

Thanks! I change the CIFS setting to log = none vs. minimal by default & the log stopped filling up.

It's not a good idea to turn off logging to stop your log from filling up.

 

[marcevan]

I entered a bug for this.

While we can say "it's a warning so choose your log level" it's kind of alarming to see that null password is deprecated but the guide still firmly tells us to allow no password and even make no password mandatory in CIFs shares.

If it's deprecated in Samba 4.19 then we need to change the logger to match the version of Samba we maxed out in CIFs service setup.