My server is CentOS with samba 3.0.25b. One client box runs Mandriva 2007.1 with samba 3.0.24. I can see the client box from the server, but the client box can't see the server. It can see the laptop on the same lan, though.
Any suggestions as to what I could check? I know Craig said there had been some significant changes in recent versions. Are any of those changes likely to have an impact on this?
Anne
On Sat, 2008-04-19 at 13:55 +0100, Anne Wilson wrote:
My server is CentOS with samba 3.0.25b. One client box runs Mandriva 2007.1 with samba 3.0.24. I can see the client box from the server, but the client box can't see the server. It can see the laptop on the same lan, though.
Any suggestions as to what I could check? I know Craig said there had been some significant changes in recent versions. Are any of those changes likely to have an impact on this?
---- are they on the same subnet?
it almost sounds like firewall rules are in the way.
Always check first from localhost and then from another machine...
from localhost...
smbclient -L localhost smbclient -L NETBIOSNAME # which is the hostname unless you set something # different in smb.conf
then from another computer...
smbclient -L IP_ADDRESS_OF_SYSTEM smbclient -L NETBIOSNAME
if localhost & IP_ADDRESS_OF_SYSTEM work but NETBIOSNAME doesn't work, you've got a problem with name resolution.
Craig
On Saturday 19 April 2008 14:40:36 Craig White wrote:
On Sat, 2008-04-19 at 13:55 +0100, Anne Wilson wrote:
My server is CentOS with samba 3.0.25b. One client box runs Mandriva 2007.1 with samba 3.0.24. I can see the client box from the server, but the client box can't see the server. It can see the laptop on the same lan, though.
Any suggestions as to what I could check? I know Craig said there had been some significant changes in recent versions. Are any of those changes likely to have an impact on this?
are they on the same subnet?
it almost sounds like firewall rules are in the way.
Always check first from localhost and then from another machine...
from localhost...
smbclient -L localhost smbclient -L NETBIOSNAME # which is the hostname unless you set something # different in smb.conf
then from another computer...
smbclient -L IP_ADDRESS_OF_SYSTEM smbclient -L NETBIOSNAME
if localhost & IP_ADDRESS_OF_SYSTEM work but NETBIOSNAME doesn't work, you've got a problem with name resolution.
All four requested the user password, then returned a summary of the shares. The LAN name is correct. The client in question, though, is names as master, which it shouldn't be.
Anne
On Sat, 2008-04-19 at 15:46 +0100, Anne Wilson wrote:
On Saturday 19 April 2008 14:40:36 Craig White wrote:
On Sat, 2008-04-19 at 13:55 +0100, Anne Wilson wrote:
My server is CentOS with samba 3.0.25b. One client box runs Mandriva 2007.1 with samba 3.0.24. I can see the client box from the server, but the client box can't see the server. It can see the laptop on the same lan, though.
Any suggestions as to what I could check? I know Craig said there had been some significant changes in recent versions. Are any of those changes likely to have an impact on this?
are they on the same subnet?
it almost sounds like firewall rules are in the way.
Always check first from localhost and then from another machine...
from localhost...
smbclient -L localhost smbclient -L NETBIOSNAME # which is the hostname unless you set something # different in smb.conf
then from another computer...
smbclient -L IP_ADDRESS_OF_SYSTEM smbclient -L NETBIOSNAME
if localhost & IP_ADDRESS_OF_SYSTEM work but NETBIOSNAME doesn't work, you've got a problem with name resolution.
All four requested the user password, then returned a summary of the shares. The LAN name is correct. The client in question, though, is names as master, which it shouldn't be.
---- LAN NAME? what's a LAN NAME?
There's a WORKGROUP concept in samba...
any machine on the subnet should give the same answer with the following command...
nmblookup -M WORKGROUP # obviously substitute for the 'WORKGROUP' whatever name # you use for workgroup
This is a live broadcast poll of the subnet and reply should come from the 'Browse Master' from the most recent 'election' - elections occur every 15 minutes by design.
If you are getting different results from the same subnet on different machines then, as I suggested on the thread on fedora-list, make sure that all the Linux systems on the LAN set os level = 20 (the default) except for the one you want to be the master where it's set to os level = 65
Craig
On Saturday 19 April 2008 16:05:09 Craig White wrote:
On Sat, 2008-04-19 at 15:46 +0100, Anne Wilson wrote:
On Saturday 19 April 2008 14:40:36 Craig White wrote:
On Sat, 2008-04-19 at 13:55 +0100, Anne Wilson wrote:
My server is CentOS with samba 3.0.25b. One client box runs Mandriva 2007.1 with samba 3.0.24. I can see the client box from the server, but the client box can't see the server. It can see the laptop on the same lan, though.
Any suggestions as to what I could check? I know Craig said there had been some significant changes in recent versions. Are any of those changes likely to have an impact on this?
are they on the same subnet?
it almost sounds like firewall rules are in the way.
Always check first from localhost and then from another machine...
from localhost...
smbclient -L localhost smbclient -L NETBIOSNAME # which is the hostname unless you set something # different in smb.conf
then from another computer...
smbclient -L IP_ADDRESS_OF_SYSTEM smbclient -L NETBIOSNAME
if localhost & IP_ADDRESS_OF_SYSTEM work but NETBIOSNAME doesn't work, you've got a problem with name resolution.
All four requested the user password, then returned a summary of the shares. The LAN name is correct. The client in question, though, is names as master, which it shouldn't be.
LAN NAME? what's a LAN NAME?
OK - workgroup name, if you prefer it.
There's a WORKGROUP concept in samba...
any machine on the subnet should give the same answer with the following command...
nmblookup -M WORKGROUP # obviously substitute for the 'WORKGROUP' whatever name # you use for workgroup
This is a live broadcast poll of the subnet and reply should come from the 'Browse Master' from the most recent 'election' - elections occur every 15 minutes by design.
If you are getting different results from the same subnet on different machines then, as I suggested on the thread on fedora-list, make sure that all the Linux systems on the LAN set os level = 20 (the default) except for the one you want to be the master where it's set to os level = 65
The laptop I'm working from and the client in question both return exactly the same -
nmblookup -M lydgate.lan querying lydgate.lan on 192.168.0.255 192.168.0.30 lydgate.lan<1d>
The server has os level = 66 set. The client doesn't have any setting at all for os level so should be working at the default. 192.168.0.30 is the badly behaved client, not the server.
Anne
On Sat, 2008-04-19 at 16:24 +0100, Anne Wilson wrote:
On Saturday 19 April 2008 16:05:09 Craig White wrote:
On Sat, 2008-04-19 at 15:46 +0100, Anne Wilson wrote:
On Saturday 19 April 2008 14:40:36 Craig White wrote:
On Sat, 2008-04-19 at 13:55 +0100, Anne Wilson wrote:
My server is CentOS with samba 3.0.25b. One client box runs Mandriva 2007.1 with samba 3.0.24. I can see the client box from the server, but the client box can't see the server. It can see the laptop on the same lan, though.
Any suggestions as to what I could check? I know Craig said there had been some significant changes in recent versions. Are any of those changes likely to have an impact on this?
are they on the same subnet?
it almost sounds like firewall rules are in the way.
Always check first from localhost and then from another machine...
from localhost...
smbclient -L localhost smbclient -L NETBIOSNAME # which is the hostname unless you set something # different in smb.conf
then from another computer...
smbclient -L IP_ADDRESS_OF_SYSTEM smbclient -L NETBIOSNAME
if localhost & IP_ADDRESS_OF_SYSTEM work but NETBIOSNAME doesn't work, you've got a problem with name resolution.
All four requested the user password, then returned a summary of the shares. The LAN name is correct. The client in question, though, is names as master, which it shouldn't be.
LAN NAME? what's a LAN NAME?
OK - workgroup name, if you prefer it.
There's a WORKGROUP concept in samba...
any machine on the subnet should give the same answer with the following command...
nmblookup -M WORKGROUP # obviously substitute for the 'WORKGROUP' whatever name # you use for workgroup
This is a live broadcast poll of the subnet and reply should come from the 'Browse Master' from the most recent 'election' - elections occur every 15 minutes by design.
If you are getting different results from the same subnet on different machines then, as I suggested on the thread on fedora-list, make sure that all the Linux systems on the LAN set os level = 20 (the default) except for the one you want to be the master where it's set to os level = 65
The laptop I'm working from and the client in question both return exactly the same -
nmblookup -M lydgate.lan querying lydgate.lan on 192.168.0.255 192.168.0.30 lydgate.lan<1d>
The server has os level = 66 set. The client doesn't have any setting at all for os level so should be working at the default. 192.168.0.30 is the badly behaved client, not the server.
---- lydgate.lan - is that the name of your workgroup?
That seems to be a hostname too which I think is part of the confusion
Craig
On Saturday 19 April 2008 16:39:37 Craig White wrote:
The laptop I'm working from and the client in question both return exactly the same -
nmblookup -M lydgate.lan querying lydgate.lan on 192.168.0.255 192.168.0.30 lydgate.lan<1d>
The server has os level = 66 set. The client doesn't have any setting at all for os level so should be working at the default. 192.168.0.30 is the badly behaved client, not the server.
lydgate.lan - is that the name of your workgroup?
Yes
That seems to be a hostname too which I think is part of the confusion
The client in question is borg.lydgate.lan. This laptop, that has no problems, is anne-wireless.lydgate.lan.
Anne
On Sat, 2008-04-19 at 16:24 +0100, Anne Wilson wrote:
On Saturday 19 April 2008 16:05:09 Craig White wrote:
On Sat, 2008-04-19 at 15:46 +0100, Anne Wilson wrote:
On Saturday 19 April 2008 14:40:36 Craig White wrote:
On Sat, 2008-04-19 at 13:55 +0100, Anne Wilson wrote:
My server is CentOS with samba 3.0.25b. One client box runs Mandriva 2007.1 with samba 3.0.24. I can see the client box from the server, but the client box can't see the server. It can see the laptop on the same lan, though.
Any suggestions as to what I could check? I know Craig said there had been some significant changes in recent versions. Are any of those changes likely to have an impact on this?
are they on the same subnet?
it almost sounds like firewall rules are in the way.
Always check first from localhost and then from another machine...
from localhost...
smbclient -L localhost smbclient -L NETBIOSNAME # which is the hostname unless you set something # different in smb.conf
then from another computer...
smbclient -L IP_ADDRESS_OF_SYSTEM smbclient -L NETBIOSNAME
if localhost & IP_ADDRESS_OF_SYSTEM work but NETBIOSNAME doesn't work, you've got a problem with name resolution.
All four requested the user password, then returned a summary of the shares. The LAN name is correct. The client in question, though, is names as master, which it shouldn't be.
LAN NAME? what's a LAN NAME?
OK - workgroup name, if you prefer it.
There's a WORKGROUP concept in samba...
any machine on the subnet should give the same answer with the following command...
nmblookup -M WORKGROUP # obviously substitute for the 'WORKGROUP' whatever name # you use for workgroup
This is a live broadcast poll of the subnet and reply should come from the 'Browse Master' from the most recent 'election' - elections occur every 15 minutes by design.
If you are getting different results from the same subnet on different machines then, as I suggested on the thread on fedora-list, make sure that all the Linux systems on the LAN set os level = 20 (the default) except for the one you want to be the master where it's set to os level = 65
The laptop I'm working from and the client in question both return exactly the same -
nmblookup -M lydgate.lan querying lydgate.lan on 192.168.0.255 192.168.0.30 lydgate.lan<1d>
The server has os level = 66 set. The client doesn't have any setting at all for os level so should be working at the default. 192.168.0.30 is the badly behaved client, not the server.
---- ok, just had another thought...
on each machine that has nmb running...
# cat /var/cache/samba/wins.dat on other distributions, the location of wins.dat will surely change
the entire discussion of network browsing can be found here... http://samba.org/samba/docs/man/Samba-HOWTO-Collection/NetworkBrowsing.html
and specific information on how to 'game' the various systems to influence the outcome of Network Browsing is here... http://samba.org/samba/docs/man/Samba-HOWTO-Collection/NetworkBrowsing.html#...
Craig
On Saturday 19 April 2008 16:51:42 Craig White wrote:
On Sat, 2008-04-19 at 16:24 +0100, Anne Wilson wrote:
On Saturday 19 April 2008 16:05:09 Craig White wrote:
On Sat, 2008-04-19 at 15:46 +0100, Anne Wilson wrote:
On Saturday 19 April 2008 14:40:36 Craig White wrote:
On Sat, 2008-04-19 at 13:55 +0100, Anne Wilson wrote:
My server is CentOS with samba 3.0.25b. One client box runs Mandriva 2007.1 with samba 3.0.24. I can see the client box from the server, but the client box can't see the server. It can see the laptop on the same lan, though.
Any suggestions as to what I could check? I know Craig said there had been some significant changes in recent versions. Are any of those changes likely to have an impact on this?
are they on the same subnet?
it almost sounds like firewall rules are in the way.
Always check first from localhost and then from another machine...
from localhost...
smbclient -L localhost smbclient -L NETBIOSNAME # which is the hostname unless you set something # different in smb.conf
then from another computer...
smbclient -L IP_ADDRESS_OF_SYSTEM smbclient -L NETBIOSNAME
if localhost & IP_ADDRESS_OF_SYSTEM work but NETBIOSNAME doesn't work, you've got a problem with name resolution.
All four requested the user password, then returned a summary of the shares. The LAN name is correct. The client in question, though, is names as master, which it shouldn't be.
LAN NAME? what's a LAN NAME?
OK - workgroup name, if you prefer it.
There's a WORKGROUP concept in samba...
any machine on the subnet should give the same answer with the following command...
nmblookup -M WORKGROUP # obviously substitute for the 'WORKGROUP' whatever name # you use for workgroup
This is a live broadcast poll of the subnet and reply should come from the 'Browse Master' from the most recent 'election' - elections occur every 15 minutes by design.
If you are getting different results from the same subnet on different machines then, as I suggested on the thread on fedora-list, make sure that all the Linux systems on the LAN set os level = 20 (the default) except for the one you want to be the master where it's set to os level = 65
The laptop I'm working from and the client in question both return exactly the same -
nmblookup -M lydgate.lan querying lydgate.lan on 192.168.0.255 192.168.0.30 lydgate.lan<1d>
The server has os level = 66 set. The client doesn't have any setting at all for os level so should be working at the default. 192.168.0.30 is the badly behaved client, not the server.
ok, just had another thought...
on each machine that has nmb running...
# cat /var/cache/samba/wins.dat on other distributions, the location of wins.dat will surely change
Neither the client in question nor this one have wins.dat, according to locate.
the entire discussion of network browsing can be found here... http://samba.org/samba/docs/man/Samba-HOWTO-Collection/NetworkBrowsing.html
and specific information on how to 'game' the various systems to influence the outcome of Network Browsing is here... http://samba.org/samba/docs/man/Samba-HOWTO-Collection/NetworkBrowsing.html #id2579338
I have to leave this for a couple of hours, but I'll read them when I get back.
Anne
Unbelievably simple, once I found it. /etc/hosts had lost several lines. I have no idea how that could have happened, but one of the missing lines was the address of the server. I can now see all the server's shares within konqueror!
Thanks for all the help. It was starting reading the howto that made me realise that checking that file would be sensible. I would never have thought of that. Another lesson learned :-)
Anne
Anne Wilson wrote:
Unbelievably simple, once I found it. /etc/hosts had lost several lines. I have no idea how that could have happened, but one of the missing lines was the address of the server. I can now see all the server's shares within konqueror!
Yes, that would indeed do it..
However, there has in "recent" years been made some progress in this field, and DNS has solved the issue of hosts-files being corrupted or out of sync between machines on the local network..
It might be worth the effort to set up dhcp with ddns updates - it makes such interoperability a piece of cake!
-
Anne Wilson -
Craig White -
Morten Nilsen