[Samba] Linux update knobbles Samba - Samba

This is a discussion on [Samba] Linux update knobbles Samba - Samba ; 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 ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: [Samba] Linux update knobbles Samba

  1. [Samba] Linux update knobbles Samba

    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?

    * 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)

    * 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.

    * 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

    ** Commands smbclient -L LinuxServer and smbclient -L XPHomeClient both show the
    shares expected. smbclient -L XPHomeClient does not show a workgroup.

    ** nmblookup -M CommonWorkgroup
    gets a positve response from XPHomeClient and the workgroup is found. This
    appears to be correct, CommonWorkgroup is MSHOME.

    ** 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.

    * 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.

    ** Second, double-clicking on the Samba Browser button in Konqueror
    does not do anything; this would bring up information under Mandriva 2007. 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?

    * 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.

    [2008/07/01 12:51:08, 0] nmbd/nmbd_incomingrequests.crocess_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.crocess_name_refresh_request(173)
    Error - should be sent to WINS server
    [2008/07/01 12:51:08, 0] nmbd/nmbd_incomingrequests.crocess_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.crocess_name_refresh_request(173)
    Error - should be sent to WINS server
    [2008/07/01 12:51:08, 0] nmbd/nmbd_incomingrequests.crocess_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.crocess_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.

    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.

    ** /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.

    --
    To unsubscribe from this list go to the following URL and read the
    instructions: https://lists.samba.org/mailman/listinfo/samba

  2. Re: [Samba] Linux update knobbles Samba

    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?

    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

    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

    _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.

    > ** 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).

    > ** 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!

    > ** 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 ?

    > ** 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.

    > 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.

    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.

    > * 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?

    > [2008/07/01 12:51:08, 0]
    > nmbd/nmbd_incomingrequests.crocess_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.crocess_name_refresh_request(173) Error -
    > should be sent to WINS server
    > [2008/07/01 12:51:08, 0]
    > nmbd/nmbd_incomingrequests.crocess_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.crocess_name_refresh_request(173) Error -
    > should be sent to WINS server
    > [2008/07/01 12:51:08, 0]
    > nmbd/nmbd_incomingrequests.crocess_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.crocess_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
    --
    To unsubscribe from this list go to the following URL and read the
    instructions: https://lists.samba.org/mailman/listinfo/samba

  3. Re: [Samba] Linux update knobbles Samba

    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.crocess_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.crocess_name_refresh_request(173) Error -
    > > should be sent to WINS server
    > > [2008/07/01 12:51:08, 0]
    > > nmbd/nmbd_incomingrequests.crocess_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.crocess_name_refresh_request(173) Error -
    > > should be sent to WINS server
    > > [2008/07/01 12:51:08, 0]
    > > nmbd/nmbd_incomingrequests.crocess_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.crocess_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



    --
    To unsubscribe from this list go to the following URL and read the
    instructions: https://lists.samba.org/mailman/listinfo/samba

  4. Re: [Samba] Linux update knobbles Samba

    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.crocess_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.crocess_name_refresh_request(173) Error -
    > > > should be sent to WINS server
    > > > [2008/07/01 12:51:08, 0]
    > > > nmbd/nmbd_incomingrequests.crocess_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.crocess_name_refresh_request(173) Error -
    > > > should be sent to WINS server
    > > > [2008/07/01 12:51:08, 0]
    > > > nmbd/nmbd_incomingrequests.crocess_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.crocess_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.
    --
    To unsubscribe from this list go to the following URL and read the
    instructions: https://lists.samba.org/mailman/listinfo/samba

  5. Re: [Samba] Linux update knobbles Samba

    > Hey, pardon me for breaking in here - but those actiontec routers are
    > really crap,

    Great stuff, Charlie, there is nothing like getting to the point right
    away 8-)

    > I have one and my father has one as well. They go schizo
    > at fairly predictable intervals, my dad has to power-cycle his (unplug
    > from wall, wait a few seconds, plug back in) every three months. I
    > have only had mine for two months, but I've had to do it once already.
    > I presume this is because I use mine harder; I have a fairly busy
    > home network and my dad has only his Ubuntu and Mac machines.

    We have had ours for years, it came via the telephone company with
    DSL. We have had to do some power-cycling as you describe. It has
    never been a big deal, but I shall think about it some more.

    >
    > In your shoes, I would power down everything and reboot - bring up
    > the

    It happens that we just had a power failure when the house re-modelling
    across the way involved the Bobcat attacking the electricity cable. The
    computers are on UPSes, but not the modem; I am in the process of
    changing that.

    > actiontec and any other switch or router tackle first, then the linux
    > box, then the Windows. You might find everything magically works (or
    > not, but at least you will have a clean test environment for figuring
    > out what is wrong).

    So, I tried all that by default. Thanks for the suggestion though.
    dajo

    >
    > --Charlie
    >
    > On 7/6/08, David Outteridge wrote:
    > >> On Tuesday 01 July 2008 21:37:31 David Outteridge wrote:
    > >>
    > >> > * 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)

    --
    To unsubscribe from this list go to the following URL and read the
    instructions: https://lists.samba.org/mailman/listinfo/samba

+ Reply to Thread