[Samba] Linux update knobbles Samba
David Outteridge
dajo at frii.com
Mon Jul 7 01:06:41 GMT 2008
Hello John,
I am replying to this mail to you directly, as suggested; I shall reply
to your other mail via the list.
First and foremost, thank you so much for taking the trouble to reply as you
have; that is very much appreciated whatever the outcome of my original
posting.
Jumping to your last comments here: I *have* read quite a lot of Samba
documentation, starting at the HOWTO, going via What If Things Don't Work? and
into The Samba Checklist. I baulked at Analyzing and Solving Samba Problems;
with the justification that it is rather ludicrous to require a *user* to do
things such as running Samba inside GDB; and with the rationale that that
procedure is highly unlikely to be necessary to solve my problem. My network
is trivial, and I am really rather confident that when I find out what the
problem is, it will be very "obvious" what I should have done. If you were to
compare the ordering of what I put in my posting (it is not worth actually
doing that) I think that you would find reasonable correspondance with the
ordering of the Samba Checklist. I left out several steps because the posting
was getting undesirably long anyway.
Here are my comments on what you wrote, maybe something constructive (and
beyond my immediate problem) will come out of it. I discovered somthing on
the way through my writing, but I did not go back and change anything that you
are going to read now because of the implicit demonstration of my learning
process.
> Dave,
>
> You got my attention because of your reply regarding a brush-off someone else
> received. I respect that you spoke up. It does all of us good to be reminded
> that we receive requests from all an sundry users.
>
> On Tuesday 01 July 2008 21:37:31 David Outteridge wrote:
> > Hello People,
> >
> > I do hope that this is not a really old problem that everyone is
> > totally sick of hearing; it is a pain in the neck problem for me right
> > now. I am just a Samba user. Help will be much appreciated 8-)
> >
> > I have been using Mandriva 2007 Linux and have installed Mandriva 2008;
> > Samba has stopped working as described below. What is wrong?
>
> Any number of things could be at fault.
>
> > * The hardware is a local LAN controlled by an Actiontec DSL gateway
> > The computers on the LAN are LinuxServer (192.168.0.3) and XPHomeClient
> > (192.168.0.99)
>
> OK - info noted.
>
> > * XPHomeClient has not been altered from its Mandriva 2007 configuration
> > except that the IP address, 192.168.0.3, of LinuxServer has been put into
> > WINS. This enables me to refer to LinuxServer by name on XPHomeClient.
>
> What do you mean by WINS? What is your understanding of what WINS is
> and does?
This is a good example of how easy it is to mis-lead others; what I have
written has mis-led you in the same way that documentation (any writing,
really) can mis-lead the uninitiated. What I wrote is shorthand for reporting
that I responded to a suggestion from the Checklist:
On the PC, type the command net view \\BIGSERVER. You will need to
do this from within a DOS prompt window. You should get back a list
of shares available on the server.
If you get a message network name not found or similar error, then
NetBIOS name resolution is not working. This is usually caused by a
problem in nmbd. To overcome it, you could do one of the following
(you only need to choose one of them):
1. Fix the nmbd installation.
2. Add the IP address of BIGSERVER to the wins server box in the
advanced TCP/IP setup on the PC.
3. ....
I got something like name not found; so, not having the first idea of how to
fix the nmdb installation, I put the IP of my LinuxServer in the WINS server
box (that is where the original "WINS" came from - it is a tab name in the XP
popup) in the advanced TCP/IP setup on XPHomeClient. And I thought that this
enabled me to refer to LinuxServer by name rather than by IP address, I am
less sure now because I cannot repeat it.
>
> Just what you have said above suggests that your comprehension of WINS is
> mistaken. WINS is the Windows Internet Name Service. It is a service that
> needs to be run on a server in order to provide name resolution for NetBIOS
> names.
>
> Windows machines have NetBIOS names _IF_ they are configured to use NetBIOS
> over TCP/IP. Fortunately, that is the default in most situations - but not
> all!
>
> NetBIOS names can be resolved to an IP address via broadcast protocols that
> are part of the NetBIOS over TCP/IP protocols implementation. WINS is simply
> a means of avoiding much UDP-based broadcast traffic.
>
> So how did you put the IP address of the LinuxServer into WINS? Where did you
> do this?
>
> I think that what you have said is that you added the following to your
> smb.conf file [globals] section:
>
> wins server = 192.168.0.3
No, I did not do this. I tried wins server = 192.168.0.99, as reported below.
I did this as the result of a net search as I recall; someone has written that
this is the solution to some problem or other. It slowed down the machine
response enormously, but otherwise did not break it; and I thought that that
information might be a clue to what is going on to those who understand how
Samba works.
>
> If that is correct, you may just have broken your NetBIOS name resolution
> process a little, in that now the Samba server will try to send directed name
> resolution requests to the address 192.168.0.3 over UDP - calls that will
> have to time out if a WINS server does not exist at that address.
>
> If you want Samba to be your WINS server, the correct entry is:
>
> wins support = Yes
I tried this, reported below, because it was easy to try and because of advice
from the same net search that made me try setting a wins server. But I did
not expect anything useful because the man page for smb.conf more or less
warned me off.
>
> _AND_ your Windows client TCP/IP stack needs to be configured to use the WINS
> server. This may help to make things work better - if that addresses the
> core problem - and that has not yet been established.
>
> > * Samba on LinuxServer appears to be running well, as described below.
> > However, it appears that either samba or the OS is badly configured.
> >
> > ** testparm is error-free and shows the shares expected
>
> That is a good start.
It may be worth commenting that I have not been putting much effort into
investigating Windows XP at this point simply because I have made precisely
one change (the WINS entry) to XP, and that seems unlikely to be the problem.
In fact, I think I checked this by removing the WINS entry and using the IP
address instead in net calls - with no behavioural change. This is why I
wrote that it appears that either Samba or the OS (Mandriva) is badly
configured on my machine.
>
> > ** Commands smbclient -L LinuxServer and smbclient -L XPHomeClient both
> > show the shares expected. smbclient -L XPHomeClient does not show a
> > workgroup.
>
> OK. The fact that you can query each system is a good sign. What is the
> workgroup set to on the Windows XP Home system? You can find out by rigth
> clicking on the "My Computer" Icon, then click on "Properties", then click
> on "Computer Name" (or something like it - this is Windows stuff, nothing to
> do with Samba).
MSHOME
>
> > ** nmblookup -M CommonWorkgroup
> > gets a positve response from XPHomeClient and the workgroup is found. This
> > appears to be correct, CommonWorkgroup is MSHOME.
>
> Did you really use the name "CommonWorkgroup"? Hmmm, confusing!
LinuxServer, XPHomeClient, and CommonWorkgroup are the names I used
for the posting, I had hoped that these would be informative. The
actual names on my LAN are rednose for LinuxServer, epiphyllum for
XPHomeClient, and MSHOME for CommonWorkgroup. Here is what I just
did:
rednose dajo ~ hostname
rednose
rednose dajo ~ ping epiphyllum -c3
PING epiphyllum (192.168.0.99) 56(84) bytes of data.
64 bytes from epiphyllum (192.168.0.99): icmp_seq=1 ttl=128 time=0.476 ms
64 bytes from epiphyllum (192.168.0.99): icmp_seq=2 ttl=128 time=0.246 ms
64 bytes from epiphyllum (192.168.0.99): icmp_seq=3 ttl=128 time=0.249 ms
--- epiphyllum ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 0.246/0.323/0.476/0.109 ms
rednose dajo ~ nmblookup -M MSHOME
added interface ip=192.168.0.3 bcast=192.168.0.255 nmask=255.255.255.0
added interface ip=127.0.0.1 bcast=127.255.255.255 nmask=255.0.0.0
Socket opened.
querying MSHOME on 192.168.0.255
Got a positive name query response from 192.168.0.99 ( 192.168.0.99 )
192.168.0.99 MSHOME<1d>
rednose dajo ~ smbclient -L rednose -N
Domain=[REDNOSE] OS=[Unix] Server=[Samba 3.0.25b]
Sharename Type Comment
--------- ---- -------
homes Disk Home Directories
print$ Disk
pdf-gen Printer PDF Generator (only valid users)
Exchange Disk Exchange
NancysBackup Disk Backup under Nancy's Control
IPC$ IPC IPC Service (Samba Server 3.0.25b)
HPPSmarC51_1 Printer Colour Inkjet 600dpi
HPPSmarC5100 Printer Colour InkJet 300dpi
HPCLJet260_1 Printer Colour LaserJet 600dpi
HPCLJet2600n Printer Monochrome LaserJet 600dpi
dajo Disk Home Directories
Domain=[REDNOSE] OS=[Unix] Server=[Samba 3.0.25b]
Server Comment
--------- -------
Workgroup Master
--------- -------
MSHOME REDNOSE
rednose dajo ~ smbclient -L epiphyllum -N
Domain=[EPIPHYLLUM] OS=[Windows 5.1] Server=[Windows 2000 LAN Manager]
Sharename Type Comment
--------- ---- -------
IPC$ IPC Remote IPC
print$ Disk Printer Drivers
DavidsDisc Disk
Documents Disk
DavidsBackup Disk
Printer3 Printer HP Color LaserJet 2600n
Printer Printer HP Photosmart C5100 series
Domain=[EPIPHYLLUM] OS=[Windows 5.1] Server=[Windows 2000 LAN Manager]
Server Comment
--------- -------
Workgroup Master
--------- -------
rednose dajo ~
>
> > ** Commands smbclient LinuxServer/alistedshare and smbclient
> > XPHomeClient/alistedshare both allow access to the referent shares, and
> > put, get, and rm all work. In other words, I can transfer files to and
> > from XPHomeClient from LinuxServer.
>
> It seems you have something working.
>
> > * Now it goes wrong.
> > First, I cannot access LinuxServer from XPHomeClient
> >
> > ** net view \\LinuxServer produces the message
> > System error 53 has occurred. The network path was not found. So I cannot
> > access LinuxServer from XPHomeClient at all.
>
> And that simply means that the Windows system could not resolve the
> name "LinuxServer" to an IP Address. What happens if you type in:
> \\192.168.0.3 ?
If I type "net view \\192.168.0.3" I get exactly the same response as
for "net view \\rednose". This takes us back to the WINS server box
entry covered above.
>
> > ** Second, double-clicking on the Samba Browser button in Konqueror
> > does not do anything; this would bring up information under Mandriva 2007.
>
> This is a Mandriva question - not a Samba issue.
Well, is it? This action in this browser is something that worked under
Mandriva 2007 AND Samba 3.0.23b, but does not work under Mandriva 2008 AND
Samba 3.0.25b. I do not see that it must be the OS alone that should be
investigated. However, it may not be either of these, I am very concerned
that I made a configuration change under Mandriva 2007 that I have forgotten.
>
> > So I cannot access LinuxServer from the Konqueror browser running on
> > LinuxServer. Do I need to suppress the password request that I get with
> > smbclient? How do I do that?
>
> Question does not make sense! But it does appear that you have a name
> resolution problem. In other words, things are a bit broken.
This is more shorthand that is mis-leading. My thinking was along these
lines: "When I run smbclient -L rednose I have to supply a password (actually
empty in my case), could it be that Konqueror is making a similar call but, in
effect, needs the -N parameter. Perhaps I need to configure Konqueror to do
this, perhaps I need to configure Samba so that it will not require a
password, perhaps there is a password data file that I do not know about, and,
perhaps this will be a clue to someone who knows how Samba works."
>
> Did you consider reading any of the documentation on the Samba web site? The
> book, Samba3-ByExample, chapter 1 might have led you to a working
> installation without the frustration you clearly have right now. You know, I
> spent months writing that book to help newcomers.
I did not read Samba3-ByExample. I did read the HOWTO which led to the
Checklist. I can identify where in the Checklist things go awry. The key
problem is that the following works, (from How to Install and Test Samba, with
suitable name changes):
> Enter the following command:
> $ smbclient //yourhostname/aservice
and this does not work:
> C:\> net use m: \\servername\service
and what is written in the Checklist is:
> ... Within a few minutes, the Samba host should be listed in the
> Network Neighborhood ...
Well, I agree. But it ain't. And the documentation goes no further.
>
> > * Other Things
> >
> > ** log.nmbd is showing a set of errors
> > typified by the those below. These appear to be coming from nmbd every ten
> > minutes, rather than directly from anything that I do. I established this
> > by tailing log.nmbd.
>
> The nmbd process is the NetBIOS name resolution program. It does the
> UDP-based broadcast handling and it will operate as a WINS server when
> appropriately configured.
>
> The error messages below are trying to tell you that it can not find a WINS
> server. I wonder why?
I started to look into this again and found a mistake that I made earlier.
However, the mistake is not the problem.
When I put the IP of my LinuxServer in the WINS server box (above) I was
simply responding to what is written in the Samba Checklist. I did not think
about that too much, but it appeared to work, so I took it; I think that there
is some time delay in there that was messing up my experiments. Now I have
realised that I was telling XP to use LinuxServer as its WINS server -
"obvious", now. So, I have removed that entry, and the log.nmbd error
messages stopped when I commented the wins support = yes line some time ago.
But now I cannot use a name on XPHomeClient to refer to LinuxServer, I must
use an IP address. This is ok with me; I want a minimal working
configuration; I can add bells, etc. later.
What this does is highlight the problem. I can:
* successfully ping XPHomeClient by name from LinuxServer
* successfully ping LinuxServer by IP address from XPHomeClient
* successfully smbclient -L XPHomeClient by name from LinuxServer (and use -N for no pw)
* successfully net view XPHomeClient by name from XPHomeClient
.. but not net view LinuxServer from XPHomeClient, using either a name or an IP
address.
.. nor use the Konqueror Samba Browser. I suspect that the cause is my
mis-configuration of either the OS on LinuxServer, or Samba on
LinuxServer, rather than a fault in Konqueror.
So, at this point, my XP code has not changed at all from what was used
successfully under Mandriva 2007. The things that have changed are the
LinuxServer OS version, the Samba version, and any configuration entries that
I made before and have forgotten about. The most likely problem being my
configuration.
>
> > [2008/07/01 12:51:08, 0]
> > nmbd/nmbd_incomingrequests.c:process_name_refresh_request(172)
> > process_name_refresh_request: unicast name registration request received
> > for name XPHomeClient<20> from IP 192.168.0.99 on subnet UNICAST_SUBNET.
> > [2008/07/01 12:51:08, 0]
> > nmbd/nmbd_incomingrequests.c:process_name_refresh_request(173) Error -
> > should be sent to WINS server
> > [2008/07/01 12:51:08, 0]
> > nmbd/nmbd_incomingrequests.c:process_name_refresh_request(172)
> > process_name_refresh_request: unicast name registration request received
> > for name XPHomeClient<00> from IP 192.168.0.99 on subnet UNICAST_SUBNET.
> > [2008/07/01 12:51:08, 0]
> > nmbd/nmbd_incomingrequests.c:process_name_refresh_request(173) Error -
> > should be sent to WINS server
> > [2008/07/01 12:51:08, 0]
> > nmbd/nmbd_incomingrequests.c:process_name_refresh_request(172)
> > process_name_refresh_request: unicast name registration request received
> > for name MSHOME<00> from IP 192.168.0.99 on subnet UNICAST_SUBNET.
> > [2008/07/01 12:51:08, 0]
> > nmbd/nmbd_incomingrequests.c:process_name_refresh_request(173) Error -
> > should be sent to WINS server
> >
> > ** Using configuration options
> > wins support = yes --- does not do anything that I can detect.
>
> It helps to read the documentation. It is documented.
>
> > wins server = 192.168.0.99 --- does not do anything to the displayed output
> > that I can detect; however, it slows down the response enormously - from
> > instant to several seconds.
>
> Ditto the documentation.
>
> > ** /etc/hosts
> > contains LinuxServer and XPHomeClient
> >
> > ** /etc/hosts.allow
> > putting the IP address of XPHomeClient in this file does not do anything
> > that I can detect. net view \\LinuxServer does not work either way.
>
> There are not enought hours in the day for all those who regularly respond on
> this list to help everyone that posts a request for help over their hurdles.
> The documentation was written with the intent that it would function as a
> first port of call.
>
> http://www.samba.org/samba/docs/Samba3-HOWTO.pdf
> http://www.samba.org/samba/docs/Samba3-ByExample.pdf
>
> Both books are available from your nearest book store if you need them in
> printed form. They are also in HTML form on the web site.
>
> If you still have a problem, email me directly - I'll help you further.
>
> Cheers,
> John T.
>
> Author:
> The Official Samba-3 HOWTO & Reference Guide, 2 Ed., ISBN: 0131882228
> Samba-3 by Example, 2 Ed., ISBN: 0131882221X
6 Jul 2008
Today I reviewed everything, tried it all again, and started to read
ByExample. I get back to the same place everytime. Samba is working
correctly, but there is some configuration issue that is wrong; it could be an
operating system configuration error. But it definitely has me beat. The
Samba documentation does not help because it assumes without question, in both
By Example and The Samba Checklist, that something will happen; and that
something does not happen, and I suspect is the clue to the problem. I have
had to give up because I am spending too much time on this issue; I can to do
my file transfer from the command line on my server. Perhaps I shall stumble
on the Samba solution one day.
John, you are very wrong in your assumption that I have not been reading the
documentation. However, I have not read everything; there is rather a lot of
it.
Thank you very much for your response; that is appreciated.
dajo
More information about the samba
mailing list