Under some circumstances, smbd records the name of the client as its IP address.
Was testing CVS/SAMBA_3_0 in a plaintext authorisation environment (UNIX/NIS).
Initially having trouble, but then realised I needed explicit:
"encrypt passwords = no"
But, having done this, I noticed that the log file was not longer:
but rather had become:
Quoting Victor Meldrew (of UK television fame): "I don't believe it".
Similarly, other things around smbd (e.g. utmp) that should have been given
a name were instead being given an address.
So I repeated it, switching back and forth between two smb.conf's whose only
difference was the "encrypt passwords" setting. Sure enough, the name of the
chosen logfile switched with that "encrypt password" binary switch.
Curiouser and curiouser...
I *think* what may be happening is the following:
1. Relatively early in the life of the "smbd", "smbd/server.c" is calling:
so that the supposed name at least gets set to something.
2. With NTLM (etc.), i.e. with "encrypt password = yes", this is getting replaced
(correctly) in "auth/auth_ntlmssp.c" with:
But with other auth mechanisms, this replacement fails to get done.
Is the above analysis broadly correct?
If so, then it seems that either every "auth/auth*.c" should do a similar
"set_remote_machine_name()" call, or (perhaps better) something more generic
should do this call, independent of auth mechanism(s).
If someone on the Samba Team can "own" this bug, I'd be happy to work with them,
under their advice, to try to fix it.
Is this affecting real functionality besides just informational names?
I agree, it's not a nice behavior, but the priority and severity are rather high
for simple log name issues.
BTW, you really should specify which substitution variable you are using.
Also, "net" component is the "net" command...our fault for not being more clear
in the component choices, so this doesn't really belong there...though I'm not
sure where I'd put it in the current list of components. Something for us to
Thanks for the comment, Jim.
The name of the log file is just one symptom, of potentially many others (such
as utmp), of the "name" being wrong. I presume that anything else that
subsequently depended upon "get_remote_machine_name()", such as "%m"
substitutions, will also
Incidentally, in the first symptom that I spotted, the logfile name, I have "log
file" using "%m" in its path. (Yes, you're right, Jim: I should have specified
that in the bug report. In my defence, I'd say that I was trying to concentrate
on whether I could actually go even further and suggest a source-code fix.)
Possibly I set the priority too high. But this is more general than merely
a logfile name. And this is a new release, where it would be very, very nice to
get it right. And I did offer to try to help to fix the source!
[ How is the "net" command related to this "set_remote_machine_name()" problem?
Or is it, too, somehow victim of something similar? ]
This problem is not really solvable. Only if we are doing NetBIOS over TCP/Port
139 we get the client's machine name in the netbios session setup. This is not
authenticated, so the client can send us anything.
If the client is coming in via port 445 this is not done at all, thus we have to
use the IP address. The ntlmssp authentication method is the only one to provide
the client's machine name in the session setup. Your way around this problem
would be to disable port 445 by saying
smb ports = 139
in your smb.conf.
smb ports = 139 does NOT solve the problem
originally reported against 3.0aph24. Bugzilla spring cleaning.
Removing old alpha versions.