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" in smb.conf. But, having done this, I noticed that the log file was not longer: log.<name-of-PC> but rather had become: log.<IP-address-of-PC> 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: set_remote_machine_name(get_socket_addr(...), ...) 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: set_remote_machine_name(<proper_name>, ...) 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 think about.
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 be affected. 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? ] Thanks again.
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.