[Samba] Linux update knobbles Samba
John H Terpstra
jht at samba.org
Mon Jul 7 03:50:12 GMT 2008
On Sunday 06 July 2008 20:06:41 David Outteridge wrote:
> Hello John,
>
> I am replying to this mail to you directly, as suggested; I shall reply
> to your other mail via the list.
Your reply went to the list, so this response is also.
> 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.
It really is a pleasure to interact with Samba users.
> 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.
Put plainly, the documentation is in need of much improvement. I've spent
over 1 year full time to produce the documentation that exists now. The
entire source for the books is available under the GPL. Everyone is welcome
to contibute updates and improvements.
There are many hidden assumptions behind the documentation. As I work on
improvements I will give some thought to documentation of these.
> 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.
Samba is open source software. Noone will force you to do anything against
your will, however, Windows file and print networking is complex and Samba is
certainly not free of defects. Your challenge is to get it working. When
and if you identify a Samba bug, it is up to you to provide enough
information so that the developers can fix the problem.
Samba comes with no warranty, and their liability of the developers is exactly
equal to what Samba costs. This is jsut another way of saying that Samba is
user supported software. The responsibilities that go with that may not be
compatible with your wishes.
> 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.
That is most likely the case.
> 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.
The best advice for getting help from the list is to keep your postings short
and your requests explicit. - I know - this is a gross generalization and
probably obvious to you. No offense is meant.
> 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.
Learning is a process for which there are very few effective short-cuts.
> > 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;
How long did you wait after starting the Samba server and the Windows PC? If
you are using a WINS server, things should work almost immediately. Where
WINS is not used, it can take 15-30 minutes before the network stabilizes.
If you try to execute "net view \\LinuxServer" before the network information
has stabilized you could find name resolution inoperative.
A good rule of thumb is to wait 15 minutes or more after each change.
> 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.
An absence of understanding leads to potentially breaking things further.
Welcome to Windows networking!
> > 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.
Samba simply implements Microsoft Windows networking protocols. At the
networking protocols level Samba works the way that Microsoft Windows PCs do.
The key to understanding Samba is to understand the how Windows networking
works. The trouble is that most of the good documentation on that is much
too technical for a newbie.
> > 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.
I don't know what alarmed you about the man page, but in any case, WINS is a
good thing - IF it is correctly configured. For that you do need to follow
the Windows networking rules.
> > _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.
Now you may think that you changed only one thing, but has the Windows
firewall settings been changed? Could the Windows firewall be blocking your
networking traffic?
> > > ** 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 ~
And all of this shows that Samba is working!
> > > ** 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.
Does your Windows client have the Windows firewall running?
Do you have an iptables firewall on the Linux system?
A firewall could be blocking the traffic. The fact that name resolution does
not work _AND_ it is not possible to access the Samba resources by going
directly to the IP address of the Samba server suggests that something may be
blocking the traffic.
> > > ** 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.
We have no outstanding known bugs of this sort. There are many tens of
thousands of systems that are successfully running Samba 3.0.25b. Mandriva
integrate Samba into their distribution. I do not know how Mandriva deals
with firewall configuration when Samba is installed. I do not know if they
install a firewall by default. If they do, check to see if it is running.
If it is, drop the firewall and see if this fixes the problem. If it does,
clearly this is not a Samba problem.
> > > 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.
Good thinking, but Konqueror will usually prompt for a password where one is
needed. But that depends on whether or not it can communicate with the Samba
server.
> 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.
How far should the documentation go? Are you willing to contribute written
notes to help improve the documentation. I sure can do with improvement!
I guess that will have to wait until you get it working first though.
> > > * 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.
Smells like a firewall problem, but there is still not enough information to
make a definitive diagnosis.
> What this does is highlight the problem. I can:
> * successfully ping XPHomeClient by name from LinuxServer
OK - ping gets through. Neither the Windows firewall, nor a Linux iptables
firewall are likely to block that. It does prove that your TCP/IP and
physical layer networking appear to be working.
> * successfully ping LinuxServer by IP address from XPHomeClient
Ditto.
> * successfully smbclient -L XPHomeClient by name from LinuxServer (and use
> -N for no pw) * successfully net view XPHomeClient by name from
> XPHomeClient
OK - this means that if there is a Linux iptables firewall, it is permitting
outgoing windows networking requests. This is expected.
> .. but not net view LinuxServer from XPHomeClient, using either a name or
> an IP address.
This suggests that there may be a Linux firewall that is blocking incoming
requests to port 139/tcp (the Windows network session service protocol port).
> .. nor use the Konqueror Samba Browser. I suspect that the cause is my
> mis-configuration of either the OS on LinuxServer,
It may mean that you have not installed the libsmbclient libraries.
> 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.
Or it could be that a firewall is blocking your traffic - this is worth
checking.
> 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.
I did not know what to assume. If I did you any injustice please accept my
public apology. No offense was intended.
> Thank you very much for your response; that is appreciated.
Cheers,
John T.
More information about the samba
mailing list