When acting as a PDC, the netlogon share is no longer accessible from Windows clients when upgrading from 3.0.23d to 3.0.25 Start -> Run and entering \\SERVER\netlogon results in \\SERVER\netlogon refers to a location that is unavailable. It could be on a hard drive on this computer, or on a network etc... If I rename my netlogon share to "netlogon2" in smb.conf and restart Samba then I can access the directory from Windows clients (but netlogon.bat isn't executed of course so this doesn't help). If I downgrade to 3.0.23d then the netlogon share is accessible. In both cases I am using the same smb.conf file.
Created attachment 2692 [details] smb.conf.txt
I cannot reproduce this. Everything works normally for me.
I need you to attach a raw network trace captured from the client using wireshark (http://www.wireshark.org/). Thanks.
To reproduce the bug Samba must be registering with a Windows Server 2003 WINS Server i.e. a line of the form wins server = 130.123.X.Y is required in the smb.conf file. Then, Start -> Run \\SERVER_WINS_NAME\Netlogon results in \\SERVER_WINS_NAME\netlogon refers to a location that is unavailable. It could be on a hard drive on this computer, or on a network ... but \\SERVER_IP_ADDRESS\Netlogon and \\SERVER_DNS_ALIAS\Netlogon succeed. (Note: SERVER_DNS_ALIAS and SERVER_WINS_NAME differ.) Note that all other shares are accessible using \\SERVER_WINS_NAME\SHARE_NAME except Netlogon. ping SERVER_WINS_NAME and ping SERVER_DNS_ALIAS resolve to SERVER_IP_ADDRESS. I can confirm that this affects 3.0.25 but does not affect 3.0.23d. (I am swapping between two VM Images which are identical apart from one having Samba 3.0.23d and the other having Samba 3.0.25. In both cases Samba is built from Source.)
Created attachment 2694 [details] updated smb.conf file wins server = was removed from my earlier smb.conf file to protect the IP address of our WINS Server. However, I now realise that this necessary for this bug report. (The IP address has been modified however :-)
Note that the Windows XP clients need also to be configured to use the Windows Server 2003 WINS Server for WINS name resolution. In our environment this is set via DHCP.
NB: In our production environment, the Samba Server, the W2K3 WINS Server and the XP Clients are (all) on different subnets.
Did you reboot the clients after upgrading the server? Note that the default for "msdfs root" was changed (as described in the release notes) and this requires a reboot of the client to pick up the change.
Hi Jerry, Good catch! I can confirm that the problem is resolved by rebooting clients in between the upgrade of Samba. I wasn't aware of the "msdfs root" change. What will be the affect of setting "msdfs root = yes" in smb.conf ? We don't currently have Vista deployed. Regards, Patrick
This is not a bug, but a change to "msdfs root" that requires a reboot of XP clients and Windows Member Servers. Thank you Jerry.
reopen and close as a dup
dup *** This bug has been marked as a duplicate of 4619 ***