Bug 229801

Created attachment 148677 [details]
smb.conf + an explanation of the problem + output from smbclient and smbstatus

Margaret,
can you check nmbd is running and see if you see any error message in the nmbd
log file ?

Also, you have both wins proxy and wins support enabled,
are your clients configured to use your server as the wins server?

Created attachment 148701 [details]
nmbd.log

Another server on another subnet successfully and is using the same smb.conf,
The successful system has samba-3.0.9 on it.

nmblookup -B chemps __SAMBA__
querying __SAMBA__ on 128.148.68.50
name_query failed to find name __SAMBA__
[root@chemps samba]# nmblookup -M chemistry
querying chemistry on 128.148.68.255
128.148.68.114 chemistry<1d>

Are you saying they are both WINS servers?
Which WINS server do your clients use?
And both try to be local masters on the network?
Are they in the same subnet?
Are your clients in the same subnet as the server?

I also se a lot of failures reaching a machine on a different network in
nmbd.log, you should check a firewall (either locally on the machine or on the
netwrok) is not blocking your netbios/smb packets.

Until I ran up2date yesterday, I was having no problems connecting to the
Windows computers.

There is a firewall around our subnets, but this server is on the same subnet as
most of the Window computers.   Also if the firewall is the problem, why are
users on Windows automatically logged into chemps.chem.brown.edu and can use the
printers on the server if so coded without problems.

The same firewall is around the server that is still working. 

One of the recent samba versions that was being run on RedHat had a similar
problem last year.  The bug was fixed in Nov.-Dec.  sometime.

I do not have SELINUX enabled on my servers.

nmap chemps

Starting nmap 3.70 ( http://www.insecure.org/nmap/ ) at 2007-02-23 14:51 EST
Interesting ports on chemps (128.148.68.50):
(The 1644 ports scanned but not shown below are in state: closed)
PORT      STATE SERVICE
22/tcp    open  ssh
53/tcp    open  domain
111/tcp   open  rpcbind
139/tcp   open  netbios-ssn
445/tcp   open  microsoft-ds
515/tcp   open  printer
548/tcp   open  afpovertcp
617/tcp   open  sco-dtmgr
631/tcp   open  ipp
804/tcp   open  unknown
818/tcp   open  unknown
946/tcp   open  unknown
1024/tcp  open  kdm
2049/tcp  open  nfs
6000/tcp  open  X11
32771/tcp open  sometimes-rpc5

Margaret I understand the culprit seem to be the update, yet I need the info I
requested to understand what is the problem and see if it is indeed a bug or
just a configuration problem that didn't show up before for some reason.

Can you also post your /etc/security/iptables file?

Simo.

PS: netbios port 138 is UDP

Created attachment 148715 [details]
iptables

I see that this case is "Leave as NEEDINFO".  What more information do you need?

I have several computers on which I would like to upgrade samba because their
current versions need a critical upgrade, but I don't want to install samba that
does not work properly.

Thank you for your time.

April 2, 2007.  I see that this bug report  was changed to "Need More Information" and "NotaBug".  Doesn't 
the first exclude the latter conclusion.  What "more  information" do you need from me?

April 2, 2007.  I see that this bug report  was changed to "Need More Information" and "NotaBug".  Doesn't 
the first exclude the latter conclusion.  What "more  information" do you need from me?

Sorry for not getting back on this before.
In comment #4 you can find 5 questions, and a comment, I got answer only to the
last question and the comment, but not to the others.
If I can't determine if it is a bug and what bug it is I can't help you. 

If you need help answering these questions, you can check with your support
contact and have them help you.

Are you saying they are both WINS servers?

I am the unix and network coordinator for two departments.  We "own" six subnets. 

We have two Wins server, one for each department, Geological Sciences and Chemistry.  The Win 
servers for the two departments sit on different subnets.  On three of the four subnets without  the 
master WINS server, we have local WINs servers which broadcast for the two master subnets.

The Chemistry WINS server has the updated smb programs.  I haven't updated the Geological Sciences
server because of the problem that I am experiencing with the Chemistry  WINS server.


Which WINS server do your clients use?

The clients on the .68  and  .171 subnet use the updated  Chemistry WINS server.  This is the 
connection that is broken.  The clients on the .124, .116., .119 subnets use the Geological Sciences 
WINS server.  The connections work beautifully.

The  smb.conf files for the  Chemistry and Geological Sciences are exact  copies of each other  except 
for specific changes which are relevant to their subnets, ie. the name of the server...

Both  WINS servers "remote announce" on the same five subnets.  They both "remote browse sync".

And both try to be local masters on the network?

The two WINS servers are masters on their networks, ie.  Chemistry on .68 and  .171 for the  workgroup 
- "Chemistry" and Geological Sciences on .124, .116, and .119 for  the workgroup - "Geology".  

Are they in the same subnet?

No, as above.  However,  if  I am on one of the  Chemistry subnets, say .68, and change my  workgroup 
to "Geology", reboot and come in with a Geology  account, I am logged into the Geology  server without  
a problem.  The geology server appears in my Network Neighborhood.  Until the last upgrade, I could 
log into the Chemistry WINS server  even if I was on a subnet that belonged to Geological Sciences.

Are your clients in the same subnet as the server?

The clients are usually on the same subnet as their WINS master, but if I change workgroups on a 
subnet, I can should be able to automatically  log into the  WINS master for the workgroup.  I can do
this for  Geological Sciences which is using samba 3.0.9-1.  I used to be able to do  this  for Chemistry, 
but can no longer because it is  running samba 3.0.10-1.  I did not change the smb.conf for Chemistry 
after the upgrade. 

I also se a lot of failures reaching a machine on a different network in
nmbd.log, you should check a firewall (either locally on the machine or on the
netwrok) is not blocking your netbios/smb packets.

For geops, the WINS server for Geological Sciences:

nmap geops

Starting nmap 3.70 ( http://www.insecure.org/nmap/ ) at 2007-04-02 13:53 EDT
Interesting ports on geops (128.148.124.140):
(The 1644 ports scanned but not shown below are in state: closed)
PORT      STATE SERVICE
22/tcp    open  ssh
111/tcp   open  rpcbind
139/tcp   open  netbios-ssn
445/tcp   open  microsoft-ds
515/tcp   open  printer
548/tcp   open  afpovertcp
617/tcp   open  sco-dtmgr
631/tcp   open  ipp
982/tcp   open  unknown
996/tcp   open  xtreelic
1024/tcp  open  kdm
1025/tcp  open  NFS-or-IIS
1026/tcp  open  LSA-or-nterm
2049/tcp  open  nfs
6000/tcp  open  X11
32770/tcp open  sometimes-rpc3


For chemps, the WINS server for ChemistryStarting nmap V. 3.00 ( www.insecure.org/nmap/ )
Interesting ports on chemps (128.148.68.50):
(The 1583 ports scanned but not shown below are in state: closed)
Port       State       Service
22/tcp     open        ssh                     
53/tcp     open        domain                  
111/tcp    open        sunrpc                  
135/tcp    filtered    loc-srv                 
139/tcp    open        netbios-ssn             
445/tcp    open        microsoft-ds            
515/tcp    open        printer                 
548/tcp    open        afpovertcp              
617/tcp    open        unknown                 
631/tcp    open        ipp                     
844/tcp    open        unknown                 
860/tcp    open        unknown                 
991/tcp    open        unknown                 
1024/tcp   open        kdm                     
1025/tcp   filtered    NFS-or-IIS              
1026/tcp   open        LSA-or-nterm            
2049/tcp   open        nfs                     
6000/tcp   open        X11             

April 2, 2007.  I see that this bug report  was changed to "Need More Information" and "NotaBug".  Doesn't 
the first exclude the latter conclusion.  What "more  information" do you need from me?

I think this bug may be a duplicate of #172713
Can you try setting wins proxy = no and see if this have any effect ?

This is not a fix or workaround, but will help us understand if it is the same
problem for which we are evaluating a solutions.

THanks for your patience.

Btw, the status is just ASSIGNED at the moment, it's neither NOTABUG, nor
NEEDINFO, we are working on it.

I have been caught up in other matters.  Tomorrow morning, my colleagues are going to try the
change to

wins proxy = no

I report back the results.

After making the change in smb.conf, ie. changing "wins proxy = yes" to "wins proxy = no",  the 
solution is closer.  

We still cannot see our server, chemps, in the Network  Neighborhood on Windows computers.  The 
improvement (minor) is that can connect to chemps through the SEARCH utility using just "chemps" or 
the full network name.  Prior to this you had to use the full network name.

nmblookup -M chemistry   (has been corrected)
128.148.68.50 chemistry<1d>

"nmblookup -B chemps __SAMBA__" still works

findsmb  show chemps as  the DMB for  CHEMISTRY.

After making the change in smb.conf, ie. changing "wins proxy = yes" to "wins proxy = no",  the 
solution is closer.  

We still cannot see our server, chemps, in the Network  Neighborhood on Windows computers.  The 
improvement (minor) is that can connect to chemps through the SEARCH utility using just "chemps" or 
the full network name.  Prior to this you had to use the full network name.

nmblookup -M chemistry   (has been corrected)
128.148.68.50 chemistry<1d>

"nmblookup -B chemps __SAMBA__" still works

findsmb  show chemps as  the DMB for  CHEMISTRY.

Ok, this bug must be a duplicate of #172713, I am marking it as such.
Please contact support, they will help you getting updated packages to fix this
bug. It will be fixed in next releases.

Thank you.

*** This bug has been marked as a duplicate of 172713 ***