RHEL-5.x, upgraded from samba 3.0.x to 3.5.4 using sernet rpms. Before upgrading I could do ("server" is behind a router, no DNS, no WINS): smbclient -L server -I ip.address and get server shares, after upgrading to 3.5.4, the same command won't work, because -I is ignored when used with "-L", smbclient tries standard name resolution and fails. The command "smbclient '\\server\share' -I ip.address" works properly. See how it goes to standard resolution immediately: $ smbclient -d 3 -L server -I 192.168.1.171 -Udummy%dummy lp_load_ex: refreshing parameters Initialising global parameters rlimit_max: rlimit_max (1024) below minimum Windows limit (16384) params.c:pm_process() - Processing configuration file "/etc/samba/smb.conf" Processing section "[global]" added interface eth0 ip=10.0.0.119 bcast=10.255.255.255 netmask=255.0.0.0 Client started (version 3.5.4). tdb(unnamed): tdb_open_ex: could not open file /var/lib/samba/gencache.tdb: Perm ission denied name_resolve_bcast: Attempting broadcast lookup for name server<0x20> resolve_lmhosts: Attempting lmhosts lookup for name server<0x20> resolve_hosts: Attempting host lookup for name server<0x20> resolve_hosts: getaddrinfo failed for name server [Temporary failure in name res olution] Connection to server failed (Error NT_STATUS_BAD_NETWORK_NAME) While with 3.0.x it went straight to the specified IP: $ smbclient -d 3 -L server -I 192.168.1.171 -Udummy%dummy lp_load: refreshing parameters Initialising global parameters params.c:pm_process() - Processing configuration file "/etc/samba/smb.conf" Processing section "[global]" added interface ip=10.0.0.119 bcast=10.255.255.255 nmask=255.0.0.0 Client started (version 3.0.33-3.15.el5_4.1). Connecting to 192.168.1.171 at port 445 <===== Connection to specified IP Doing spnego session setup (blob length=58) ... ...
Created attachment 5910 [details] git am fix for 3.5.x. Can you test this patch please. Should fix it. Jeremy.
I tested the patch and it solves the immediate "-I" problem, meaning now smbclient will use the IP and reach the server behind the router. However, there are still some issues. At the end of the "smbclient -L server -I ip.address" output I get these spurious messages: ... <share names correctly shown on the screen as expected> ... session request to 192.168.1.171 failed (Called name not present) session request to 192 failed (Called name not present) session request to *SMBSERVER failed (Called name not present) NetBIOS over TCP disabled -- no workgroup available $ This is true even on the same subnet (remote server is win7 64bit); diffing output of "smbclient -L server" and "smbclient -L server -I ip" executed on a server on the same subnet as the client will result in the following output (I would expect for the output of the 2 commands to be the same): ==== --- out1_without_I 2010-08-19 09:29:07.000000000 +0200 +++ out2_with_I 2010-08-19 09:29:00.000000000 +0200 @@ -1,5 +1,4 @@ Domain=[SERVERNAME] OS=[Windows 7 Professional 7600] Server=[Windows 7 Professional 6.1] -Domain=[SERVERNAME] OS=[Windows 7 Professional 7600] Server=[Windows 7 Professional 6.1] Sharename Type Comment --------- ---- ------- @@ -16,9 +15,7 @@ S$ Disk Condivisione predefinita T$ Disk Condivisione predefinita U$ Disk Condivisione predefinita - - Server Comment - --------- ------- - - Workgroup Master - --------- ------- +session request to 192.168.1.171 failed (Called name not present) +session request to 192 failed (Called name not present) +session request to *SMBSERVER failed (Called name not present) +NetBIOS over TCP disabled -- no workgroup available ====
Even if with an hopefully cosmetic problem, will the patch be applied?
The confusing lines session request to 192.168.1.171 failed (Called name not present) session request to 192 failed (Called name not present) session request to *SMBSERVER failed (Called name not present) NetBIOS over TCP disabled -- no workgroup available are still there in 3.6.3 if you use "-I". This is a cosmetic problem, not functional.
Jeremy fixed this upstream. So this bug also needs to be closed.