From: Stan Hoeppner on 14 May 2010 20:50 Carl G. Riches put forth on 5/14/2010 7:14 PM: > We are having a problem getting a NetApp filer to re-join a samba > domain after a move to a new network. The filer worked fine with > samba before the move. Apologies in advance for the long missive. I don't know about others here, but it sure would help me understand what the actual problem is if you would define, in detail, what you mean when you say: "a move to a new network" Does this mean: 1. A new building or wing with different switches/routers/cabling 2. A move to a different city/state/country 3. A new Windows Domain 4. A new TCP/IP network class (i.e. from C to A) Troubleshooting anything successfully is identifying what has changed between a working state and a failed state. Identify what things have changed and you should be one giant leap closer to a solution. At the very least that information will allow "me" to help you, and probably other on this list. -- Stan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
From: John H Terpstra on 14 May 2010 21:50 On 05/14/2010 07:14 PM, Carl G. Riches wrote: > We are having a problem getting a NetApp filer to re-join a samba > domain after a move to a new network. The filer worked fine with > samba before the move. Apologies in advance for the long missive. > > I've tried the following: > > - re-running the CIFS setup program on the filer > - removing the problem filer's samba account, replacing it, and > re-running the setup program on the filer > - creating a new machine account on the samba server and re- > running the setup program on the filer > > None of these worked. I also looked through a number of mailing > list postings about NetApp filers and samba but didn't find any- > thing to help. > > Has anyone gone through this before and provide insight into > this problem? Do you happen to specify in your /etc/samba/smb.conf file: interfaces = "list of interfaces" bind interfaces only = Yes If so, remove them, then retry the domain join. After successfully joining you ca re-enable these parameters. Please let me know if that is the solution. Cheers, John T. > We have the following: > > samba server: > Red Hat Enterprise Linux 5.3 > kernel 2.6.18 i868 > samba 3.0.33 > multiple network interfaces: 10.142.36.64/27 > 10.142.36.96/27 > 10.142.36.192/26 > > NetApp filer #1: > NetApp Release 7.2.4L1 > connected through VPN to samba server network 10.142.36.192/26 > > NetApp filer #2: > NetApp Release 7.3.1.1 > connected through VPN to samba server network 10.142.36.64/27 > > Each filer can ping the samba server. CIFS connections from each > filer are registered by the samba server and are logged in the file: > 0.0.0.0.log > > Each of the filers moved to a new network. Filer #1 rejoined the > domain but filer #2 can't. > > A tcpdump of the unsuccessful transaction is: > 10:42:38.137963 IP gcc-fs1.netbios-ns > mead.netbios-ns: NBT UDP > PACKET(137): MULTIHOMED REGISTRATION; REQUEST; UNICAST > 10:42:38.138165 IP mead.netbios-ns > gcc-fs1.netbios-ns: NBT UDP > PACKET(137): WACK; POSITIVE; RESPONSE; UNICAST > 10:42:58.270693 IP mead.netbios-ns > gcc-fs1.netbios-ns: NBT UDP > PACKET(137): REGISTRATION; NEGATIVE; RESPONSE; UNICAST > 10:44:11.627124 IP gcc-fs1.netbios-ns > mead.netbios-ns: NBT UDP > PACKET(137): MULTIHOMED REGISTRATION; REQUEST; UNICAST > 10:44:11.627292 IP mead.netbios-ns > gcc-fs1.netbios-ns: NBT UDP > PACKET(137): WACK; POSITIVE; RESPONSE; UNICAST > 10:44:32.309202 IP mead.netbios-ns > gcc-fs1.netbios-ns: NBT UDP > PACKET(137): REGISTRATION; NEGATIVE; RESPONSE; UNICAST > 10:45:45.665702 IP gcc-fs1.netbios-ns > mead.netbios-ns: NBT UDP > PACKET(137): MULTIHOMED REGISTRATION; REQUEST; UNICAST > 10:45:45.665803 IP mead.netbios-ns > gcc-fs1.netbios-ns: NBT UDP > PACKET(137): WACK; POSITIVE; RESPONSE; UNICAST > 10:46:06.312676 IP mead.netbios-ns > gcc-fs1.netbios-ns: NBT UDP > PACKET(137): REGISTRATION; NEGATIVE; RESPONSE; UNICAST > > Part of the samba log 0.0.0.0.log related to filer #2 is: > > [2010/05/14 16:54:52, 3] > nmbd/nmbd_winsserver.c:wins_process_name_registration_request(1138) > wins_process_name_registration_request: Group name registration for > name UWT-15<00> IP 10.208.235.134 > [2010/05/14 16:54:52, 3] > nmbd/nmbd_winsserver.c:wins_process_name_registration_request(1222) > wins_process_name_registration_request: Adding IP 255.255.255.255 to > group name UWT-15<00>. > [2010/05/14 16:54:52, 4] nmbd/nmbd_packets.c:reply_netbios_packet(940) > reply_netbios_packet: sending a reply of packet type: wins_reg > UWT-15<00> to ip 10.208.235.134 for id 39786 > [2010/05/14 16:54:52, 4] libsmb/nmblib.c:debug_nmb_packet(112) > nmb packet from 10.208.235.134(137) header: id=39786 > opcode=Registration(5) response=Yes > header: flags: bcast=No rec_avail=Yes rec_des=Yes trunc=No > auth=Yes > header: rcode=0 qdcount=0 ancount=1 nscount=0 arcount=0 > answers: nmb_name=UWT-15<00> rr_type=32 rr_class=1 ttl=345600 > answers 0 char ...... hex E0000AD0EB86 > [2010/05/14 16:54:52, 5] libsmb/nmblib.c:send_udp(779) > Sending a packet of len 62 to (10.208.235.134) on port 137 > > > Thanks, > Carl > > -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
From: Carl G. Riches on 16 May 2010 22:40 On Fri, 14 May 2010, John H Terpstra wrote: > On 05/14/2010 07:14 PM, Carl G. Riches wrote: >> We are having a problem getting a NetApp filer to re-join a samba >> domain after a move to a new network. The filer worked fine with >> samba before the move. Apologies in advance for the long missive. >> >> I've tried the following: >> >> - re-running the CIFS setup program on the filer >> - removing the problem filer's samba account, replacing it, and >> re-running the setup program on the filer >> - creating a new machine account on the samba server and re- >> running the setup program on the filer >> >> None of these worked. I also looked through a number of mailing >> list postings about NetApp filers and samba but didn't find any- >> thing to help. >> >> Has anyone gone through this before and provide insight into >> this problem? > > Do you happen to specify in your /etc/samba/smb.conf file: > interfaces = "list of interfaces" > bind interfaces only = Yes > > If so, remove them, then retry the domain join. After successfully > joining you ca re-enable these parameters. > > Please let me know if that is the solution. > That's part of the solution. The NetApp filer now shows up in Windows PC browse lists, but we still can't get a PC (or the samba server itself) to mount a CIFS file share from the filer. Does anyone have a suggestion for what to try next? Here's what I've done so far: I commented out these lines in /etc/samba/smb.conf: ; interfaces = 127.0.0.1 10.142.36.94/27 10.142.36.192/26 10.142.36.125/27 ; bind interfaces only = yes and restarted samba, then restarted CIFS on the NetApp filer. Tcpdump on the samba server now looks like this: 18:45:57.189347 IP gcc-fs1.in.gcc.biostat.washington.edu.netbios-ns > mead.in.gcc.biostat.washington.edu.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; UNICAST 18:45:57.189425 IP mead.in.gcc.biostat.washington.edu.netbios-ns > gcc-fs1.in.gcc.biostat.washington.edu.netbios-ns: NBT UDP PACKET(137): QUERY; POSITIVE; RESPONSE; UNICAST 18:45:59.137275 IP gcc-fs1.in.gcc.biostat.washington.edu.netbios-ns > mead.in.gcc.biostat.washington.edu.netbios-ns: NBT UDP PACKET(137): REGISTRATION; REQUEST; UNICAST 18:45:59.137390 IP mead.in.gcc.biostat.washington.edu.netbios-ns > gcc-fs1.in.gcc.biostat.washington.edu.netbios-ns: NBT UDP PACKET(137): REGISTRATION; POSITIVE; RESPONSE; UNICAST These message are on the filer's console: Sun May 16 18:46:29 PDT [auth.dc.DCPasswdChange.failed:error]: AUTH: The filer's attempt to change the shared password with filer's domain controller failed with status 0xc000005e: Scheduled automatic password change failed. The filer will retry in 1 hour. At this point the filer shows up in a Windows PC's browse list. An attempt to mount a share from the filer on the samba server using this command: mount -t cifs //10.208.235.134/geneva_fc /mnt -o username=cgr,domain=UWT-15 fails with this message: mount error 5 = Input/output error Refer to the mount.cifs(8) manual page (e.g.man mount.cifs) and these lines show up in /var/log/debug: May 16 18:49:49 mead kernel: Status code returned 0xc000005e NT_STATUS_NO_LOGON_SERVERS May 16 18:49:49 mead kernel: CIFS VFS: Send error in SessSetup = -5 May 16 18:49:49 mead kernel: CIFS VFS: cifs_mount failed w/return code = -5 An attempt to map the above share to a drive (Z:) on a Windows PC fails with the message: The mapped network drive could not be created because the following error has occurred: There are currently no logon servers available to service the logon request. These messages appeared on the filer's console during the drive mapping request: Sun May 16 19:01:19 PDT [auth.dc.trace.DCConnection.statusMsg:info]: AUTH: TraceDC- Starting DC address discovery for UWT-15. Sun May 16 19:01:19 PDT [auth.dc.trace.DCConnection.statusMsg:info]: AUTH: TraceDC- Found no DC addresses using generic DNS query. Sun May 16 19:01:19 PDT [auth.dc.trace.DCConnection.statusMsg:info]: AUTH: TraceDC- Starting WINS queries. Sun May 16 19:01:22 PDT [auth.dc.trace.DCConnection.statusMsg:info]: AUTH: TraceDC- Found no BDC addresses through WINS. Sun May 16 19:01:25 PDT [auth.dc.trace.DCConnection.statusMsg:info]: AUTH: TraceDC- Found no PDC addresses through WINS. Sun May 16 19:01:25 PDT [auth.dc.trace.DCConnection.statusMsg:info]: AUTH: TraceDC- DC address discovery for UWT-15 complete. 0 unique addresses found. The WINS server has been defined: options.cifs.wins_servers=10.142.36.94 which is the samba server. We have this line in the /etc/samba/smb.conf file: wins support = yes An attempt to browse to the filer fail with this message: \\gcc-fs1 is not accessible. You might not have permission to use this network resource. Contact the administrator of this server to find out if you have access permissions. The network path was not found. Both of these worked before moving them from one subnet to a new one. When I re-enable the "interfaces" and "bind interfaces" lines in /etc/samba/smb.conf the filer drops out of the Windows browse lists and this message comes up on the filer's console: gcc-fs1*> Sun May 16 19:12:07 PDT [nbt.WINS.registrationTimeout:info]: NBT: No WINS server are responding. The filer will continue to try to register with WINS. I had to remove the "interfaces" and "bind interfaces" lines from /etc/samba/smb.conf and restart CIFS on the filer to get the filer listed in Windows browse lists again. Commenting out the "hosts allow" line in /etc/samba/smb.conf doesn't seem to affect the behavior of samba with respect to the filer. What next? Thanks, Carl > > >> We have the following: >> >> samba server: >> Red Hat Enterprise Linux 5.3 >> kernel 2.6.18 i868 >> samba 3.0.33 >> multiple network interfaces: 10.142.36.64/27 >> 10.142.36.96/27 >> 10.142.36.192/26 >> >> NetApp filer #1: >> NetApp Release 7.2.4L1 >> connected through VPN to samba server network 10.142.36.192/26 >> >> NetApp filer #2: >> NetApp Release 7.3.1.1 >> connected through VPN to samba server network 10.142.36.64/27 >> >> Each filer can ping the samba server. CIFS connections from each >> filer are registered by the samba server and are logged in the file: >> 0.0.0.0.log >> >> Each of the filers moved to a new network. Filer #1 rejoined the >> domain but filer #2 can't. >> >> A tcpdump of the unsuccessful transaction is: >> 10:42:38.137963 IP gcc-fs1.netbios-ns > mead.netbios-ns: NBT UDP >> PACKET(137): MULTIHOMED REGISTRATION; REQUEST; UNICAST >> 10:42:38.138165 IP mead.netbios-ns > gcc-fs1.netbios-ns: NBT UDP >> PACKET(137): WACK; POSITIVE; RESPONSE; UNICAST >> 10:42:58.270693 IP mead.netbios-ns > gcc-fs1.netbios-ns: NBT UDP >> PACKET(137): REGISTRATION; NEGATIVE; RESPONSE; UNICAST >> 10:44:11.627124 IP gcc-fs1.netbios-ns > mead.netbios-ns: NBT UDP >> PACKET(137): MULTIHOMED REGISTRATION; REQUEST; UNICAST >> 10:44:11.627292 IP mead.netbios-ns > gcc-fs1.netbios-ns: NBT UDP >> PACKET(137): WACK; POSITIVE; RESPONSE; UNICAST >> 10:44:32.309202 IP mead.netbios-ns > gcc-fs1.netbios-ns: NBT UDP >> PACKET(137): REGISTRATION; NEGATIVE; RESPONSE; UNICAST >> 10:45:45.665702 IP gcc-fs1.netbios-ns > mead.netbios-ns: NBT UDP >> PACKET(137): MULTIHOMED REGISTRATION; REQUEST; UNICAST >> 10:45:45.665803 IP mead.netbios-ns > gcc-fs1.netbios-ns: NBT UDP >> PACKET(137): WACK; POSITIVE; RESPONSE; UNICAST >> 10:46:06.312676 IP mead.netbios-ns > gcc-fs1.netbios-ns: NBT UDP >> PACKET(137): REGISTRATION; NEGATIVE; RESPONSE; UNICAST >> >> Part of the samba log 0.0.0.0.log related to filer #2 is: >> >> [2010/05/14 16:54:52, 3] >> nmbd/nmbd_winsserver.c:wins_process_name_registration_request(1138) >> wins_process_name_registration_request: Group name registration for >> name UWT-15<00> IP 10.208.235.134 >> [2010/05/14 16:54:52, 3] >> nmbd/nmbd_winsserver.c:wins_process_name_registration_request(1222) >> wins_process_name_registration_request: Adding IP 255.255.255.255 to >> group name UWT-15<00>. >> [2010/05/14 16:54:52, 4] nmbd/nmbd_packets.c:reply_netbios_packet(940) >> reply_netbios_packet: sending a reply of packet type: wins_reg >> UWT-15<00> to ip 10.208.235.134 for id 39786 >> [2010/05/14 16:54:52, 4] libsmb/nmblib.c:debug_nmb_packet(112) >> nmb packet from 10.208.235.134(137) header: id=39786 >> opcode=Registration(5) response=Yes >> header: flags: bcast=No rec_avail=Yes rec_des=Yes trunc=No >> auth=Yes >> header: rcode=0 qdcount=0 ancount=1 nscount=0 arcount=0 >> answers: nmb_name=UWT-15<00> rr_type=32 rr_class=1 ttl=345600 >> answers 0 char ...... hex E0000AD0EB86 >> [2010/05/14 16:54:52, 5] libsmb/nmblib.c:send_udp(779) >> Sending a packet of len 62 to (10.208.235.134) on port 137 >> >> >> Thanks, >> Carl >> >> > > -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
From: Carl G. Riches on 24 May 2010 19:30 On Sun, 2010-05-16 at 19:23 -0700, Carl G. Riches wrote: > On Fri, 14 May 2010, John H Terpstra wrote: > > > On 05/14/2010 07:14 PM, Carl G. Riches wrote: > >> We are having a problem getting a NetApp filer to re-join a samba > >> domain after a move to a new network. The filer worked fine with > >> samba before the move. Apologies in advance for the long missive. > >> > >> I've tried the following: > >> > >> - re-running the CIFS setup program on the filer > >> - removing the problem filer's samba account, replacing it, and > >> re-running the setup program on the filer > >> - creating a new machine account on the samba server and re- > >> running the setup program on the filer > >> > >> None of these worked. I also looked through a number of mailing > >> list postings about NetApp filers and samba but didn't find any- > >> thing to help. > >> > >> Has anyone gone through this before and provide insight into > >> this problem? > > > > Do you happen to specify in your /etc/samba/smb.conf file: > > interfaces = "list of interfaces" > > bind interfaces only = Yes > > > > If so, remove them, then retry the domain join. After successfully > > joining you ca re-enable these parameters. > > > > Please let me know if that is the solution. > > > > That's part of the solution. The NetApp filer now shows up in Windows PC > browse lists, but we still can't get a PC (or the samba server itself) to > mount a CIFS file share from the filer. Does anyone have a suggestion for > what to try next? Here's what I've done so far: > > I commented out these lines in /etc/samba/smb.conf: > > ; interfaces = 127.0.0.1 10.142.36.94/27 10.142.36.192/26 10.142.36.125/27 > ; bind interfaces only = yes > > and restarted samba, then restarted CIFS on the NetApp filer. Tcpdump on > the samba server now looks like this: > > 18:45:57.189347 IP gcc-fs1.in.gcc.biostat.washington.edu.netbios-ns > mead.in.gcc.biostat.washington.edu.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; UNICAST > 18:45:57.189425 IP mead.in.gcc.biostat.washington.edu.netbios-ns > gcc-fs1.in.gcc.biostat.washington.edu.netbios-ns: NBT UDP PACKET(137): QUERY; POSITIVE; RESPONSE; UNICAST > 18:45:59.137275 IP gcc-fs1.in.gcc.biostat.washington.edu.netbios-ns > mead.in.gcc.biostat.washington.edu.netbios-ns: NBT UDP PACKET(137): REGISTRATION; REQUEST; UNICAST > 18:45:59.137390 IP mead.in.gcc.biostat.washington.edu.netbios-ns > gcc-fs1.in.gcc.biostat.washington.edu.netbios-ns: NBT UDP PACKET(137): REGISTRATION; POSITIVE; RESPONSE; UNICAST > > These message are on the filer's console: > > Sun May 16 18:46:29 PDT [auth.dc.DCPasswdChange.failed:error]: AUTH: The > filer's attempt to change the shared password with filer's domain > controller failed with status 0xc000005e: Scheduled automatic password > change failed. The filer will retry in 1 hour. > > At this point the filer shows up in a Windows PC's browse list. > > An attempt to mount a share from the filer on the samba server using this > command: > > mount -t cifs //10.208.235.134/geneva_fc /mnt -o username=cgr,domain=UWT-15 > > fails with this message: > > mount error 5 = Input/output error > Refer to the mount.cifs(8) manual page (e.g.man mount.cifs) > > and these lines show up in /var/log/debug: > > May 16 18:49:49 mead kernel: Status code returned 0xc000005e NT_STATUS_NO_LOGON_SERVERS > May 16 18:49:49 mead kernel: CIFS VFS: Send error in SessSetup = -5 > May 16 18:49:49 mead kernel: CIFS VFS: cifs_mount failed w/return code = -5 > > An attempt to map the above share to a drive (Z:) on a Windows PC fails > with the message: > > The mapped network drive could not be created because the following > error has occurred: > > There are currently no logon servers available to service the logon > request. > > These messages appeared on the filer's console during the drive mapping > request: > > Sun May 16 19:01:19 PDT [auth.dc.trace.DCConnection.statusMsg:info]: AUTH: TraceDC- Starting DC address discovery for UWT-15. > Sun May 16 19:01:19 PDT [auth.dc.trace.DCConnection.statusMsg:info]: AUTH: TraceDC- Found no DC addresses using generic DNS query. > Sun May 16 19:01:19 PDT [auth.dc.trace.DCConnection.statusMsg:info]: AUTH: TraceDC- Starting WINS queries. > Sun May 16 19:01:22 PDT [auth.dc.trace.DCConnection.statusMsg:info]: AUTH: TraceDC- Found no BDC addresses through WINS. > Sun May 16 19:01:25 PDT [auth.dc.trace.DCConnection.statusMsg:info]: AUTH: TraceDC- Found no PDC addresses through WINS. > Sun May 16 19:01:25 PDT [auth.dc.trace.DCConnection.statusMsg:info]: AUTH: TraceDC- DC address discovery for UWT-15 complete. 0 unique addresses found. > > The WINS server has been defined: > > options.cifs.wins_servers=10.142.36.94 > > which is the samba server. We have this line in the /etc/samba/smb.conf > file: > > wins support = yes > > An attempt to browse to the filer fail with this message: > > \\gcc-fs1 is not accessible. You might not have permission to use this > network resource. Contact the administrator of this server to find out > if you have access permissions. > > The network path was not found. > > Both of these worked before moving them from one subnet to a new one. > > When I re-enable the "interfaces" and "bind interfaces" lines in > /etc/samba/smb.conf the filer drops out of the Windows browse lists and > this message comes up on the filer's console: > > gcc-fs1*> Sun May 16 19:12:07 PDT [nbt.WINS.registrationTimeout:info]: NBT: No WINS server are responding. The filer will continue to try to register with WINS. > > I had to remove the "interfaces" and "bind interfaces" lines from > /etc/samba/smb.conf and restart CIFS on the filer to get the filer listed > in Windows browse lists again. > > Commenting out the "hosts allow" line in /etc/samba/smb.conf doesn't seem > to affect the behavior of samba with respect to the filer. > > What next? > > Thanks, > Carl > > > > > > >> We have the following: > >> > >> samba server: > >> Red Hat Enterprise Linux 5.3 > >> kernel 2.6.18 i868 > >> samba 3.0.33 > >> multiple network interfaces: 10.142.36.64/27 > >> 10.142.36.96/27 > >> 10.142.36.192/26 > >> > >> NetApp filer #1: > >> NetApp Release 7.2.4L1 > >> connected through VPN to samba server network 10.142.36.192/26 > >> > >> NetApp filer #2: > >> NetApp Release 7.3.1.1 > >> connected through VPN to samba server network 10.142.36.64/27 > >> > >> Each filer can ping the samba server. CIFS connections from each > >> filer are registered by the samba server and are logged in the file: > >> 0.0.0.0.log > >> > >> Each of the filers moved to a new network. Filer #1 rejoined the > >> domain but filer #2 can't. > >> > >> A tcpdump of the unsuccessful transaction is: > >> 10:42:38.137963 IP gcc-fs1.netbios-ns > mead.netbios-ns: NBT UDP > >> PACKET(137): MULTIHOMED REGISTRATION; REQUEST; UNICAST > >> 10:42:38.138165 IP mead.netbios-ns > gcc-fs1.netbios-ns: NBT UDP > >> PACKET(137): WACK; POSITIVE; RESPONSE; UNICAST > >> 10:42:58.270693 IP mead.netbios-ns > gcc-fs1.netbios-ns: NBT UDP > >> PACKET(137): REGISTRATION; NEGATIVE; RESPONSE; UNICAST > >> 10:44:11.627124 IP gcc-fs1.netbios-ns > mead.netbios-ns: NBT UDP > >> PACKET(137): MULTIHOMED REGISTRATION; REQUEST; UNICAST > >> 10:44:11.627292 IP mead.netbios-ns > gcc-fs1.netbios-ns: NBT UDP > >> PACKET(137): WACK; POSITIVE; RESPONSE; UNICAST > >> 10:44:32.309202 IP mead.netbios-ns > gcc-fs1.netbios-ns: NBT UDP > >> PACKET(137): REGISTRATION; NEGATIVE; RESPONSE; UNICAST > >> 10:45:45.665702 IP gcc-fs1.netbios-ns > mead.netbios-ns: NBT UDP > >> PACKET(137): MULTIHOMED REGISTRATION; REQUEST; UNICAST > >> 10:45:45.665803 IP mead.netbios-ns > gcc-fs1.netbios-ns: NBT UDP > >> PACKET(137): WACK; POSITIVE; RESPONSE; UNICAST > >> 10:46:06.312676 IP mead.netbios-ns > gcc-fs1.netbios-ns: NBT UDP > >> PACKET(137): REGISTRATION; NEGATIVE; RESPONSE; UNICAST > >> > >> Part of the samba log 0.0.0.0.log related to filer #2 is: > >> > >> [2010/05/14 16:54:52, 3] > >> nmbd/nmbd_winsserver.c:wins_process_name_registration_request(1138) > >> wins_process_name_registration_request: Group name registration for > >> name UWT-15<00> IP 10.208.235.134 > >> [2010/05/14 16:54:52, 3] > >> nmbd/nmbd_winsserver.c:wins_process_name_registration_request(1222) > >> wins_process_name_registration_request: Adding IP 255.255.255.255 to > >> group name UWT-15<00>. > >> [2010/05/14 16:54:52, 4] nmbd/nmbd_packets.c:reply_netbios_packet(940) > >> reply_netbios_packet: sending a reply of packet type: wins_reg > >> UWT-15<00> to ip 10.208.235.134 for id 39786 > >> [2010/05/14 16:54:52, 4] libsmb/nmblib.c:debug_nmb_packet(112) > >> nmb packet from 10.208.235.134(137) header: id=39786 > >> opcode=Registration(5) response=Yes > >> header: flags: bcast=No rec_avail=Yes rec_des=Yes trunc=No > >> auth=Yes > >> header: rcode=0 qdcount=0 ancount=1 nscount=0 arcount=0 > >> answers: nmb_name=UWT-15<00> rr_type=32 rr_class=1 ttl=345600 > >> answers 0 char ...... hex E0000AD0EB86 > >> [2010/05/14 16:54:52, 5] libsmb/nmblib.c:send_udp(779) > >> Sending a packet of len 62 to (10.208.235.134) on port 137 > >> > >> > >> Thanks, > >> Carl > >> > >> > > I've done some more testing on this and spent some time on the phone with NetApp support (even though they technically don't support SAMBA). There seems to be some sort of network problem with WINS, based on the additional tests. Can someone help pinpoint what the problem might be? To recap, we went from this configuration: +-(subnet a)-+ / + SAMBA server + \ +-(subnet b)-+ firewall +-<<IPsec tunnel>>-+ firewall + +-NetApp #1 \ | +--(subnet c)--+ | +-NetApp #2 to this: firewall +--<<IPsec tunnel>>--+ firewall +--(subnet a)--+ + / \ + +--(subnet d)--+ SAMBA server NetApp #2 + \ +--(subnet b)--+ firewall +--<<IPsec tunnel>>--+ firewall + \ +--(subnet e)--+ NetApp #1 In the original configuration both NetApp filers joined the domain, showed up in browser lists on PCs located on the subnets directly attached to the SAMBA server (noted as nets "a" and "b" above), and those PCs could mount shares from both filers. After the move, only NetApp #1 can join the domain. CIFS shares from NetApp #1 can be mounted on subnet "a" and subnet "b". Neither of these actions work for NetApp #2. >From a Linux client on the same network as NetApp #2, I can run this command: smbclient -L server and get a list of shares, the browse list and the workgroup list. I can run this command on that same Linux machine: nmblookup -B server __SAMBA__ and get back: querying __SAMBA__ on 10.142.36.94 10.142.36.94 __SAMBA__<00> It's also possible to query a Windows PC on the SAMBA server network: # nmblookup -B win-pc '*' querying * on 10.142.36.70 10.142.36.70 *<00> But queries of NetApp #2 produce this when run on the SAMBA server: querying * on 10.208.235.134 name_query failed to find name * The same happens on the Linux client that is on the same subnet as NetApp #2. I ran tdbdump on this file: /var/cache/samba/wins.tdb I don't know if it makes any difference, but there is an entry for NetApp #2 in there. Does anyone have a suggestion on what the problem might be? Thanks Carl -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
|
Pages: 1 Prev: Unix password sync Next: Samba4 and group policy password policy |