Hello,
just installed the new test2-severn CDs (fresh install), and I'm stuck right now in some trouble using samba.
I'm not able any more to contact with an WinXP-Box after configuration with the redhat-config-samba tool (there are still some bugs inside the grafical tool, for exampe when writing down my workgroup which is written in great caps, it converts automatically to small caps)
So right now, I'm able to "see" the samba-box from my WinXp-System, but I can't browse the shares of the linux-box.
In a previous posting, there were some hints about the authentification mode, but I didnt't figured out the proper parameters in smb.conf.
Another point is that browsing the network from Nautilus with smb:// doesn't work anymore too, with the last release 0.93 I didnt't had any Problems.
Can someone give me a hint, please ?
Thank you in advance
Rainer
On Fri, 2003-09-26 at 14:29, Rainer Hattenhauer wrote:
So right now, I'm able to "see" the samba-box from my WinXp-System, but I can't browse the shares of the linux-box.
In a previous posting, there were some hints about the authentification mode, but I didnt't figured out the proper parameters in smb.conf.
Another point is that browsing the network from Nautilus with smb:// doesn't work anymore too, with the last release 0.93 I didnt't had any Problems.
Can someone give me a hint, please ?
Try:
map to guest = Bad User
Browsing Samba servers anonymously (ie, no name/password) is disabled by default now (for obvious security reasons) - you must explicitly enable it.
On Fri, Sep 26, 2003 at 08:29:44PM +0200, Rainer Hattenhauer wrote:
Hello,
just installed the new test2-severn CDs (fresh install), and I'm stuck right now in some trouble using samba.
....
So right now, I'm able to "see" the samba-box from my WinXp-System, but I can't browse the shares of the linux-box.
I just happen to spent the previous night on a customer site where various Windoze clients recently started loosing connections, ability to browse and similar. There were some indications of hardware problems on their Samba server, so I was led astray a bit, but in the final account this turned out to be our "friends" from VeriSign at the root cause of all troubles. Client machines were randomly trying to connect to port 139 at 'sitefinder-<whatever>', obviously failing as they were blocked from doing such stunts, and were going bonkers.
A solution turned out to be to explictitely declare a name resolution order to 'winbind lmhosts ....', or whatever that is called, in smb.conf. I do not have Samba here so I cannot check that directive but it is mentioned explicitely in one of 'BROWSING' documents.
It does not mean that this is a problem you are seeing but I would not exclude that outright. DNS wildcard disease seems to be spreading. Today I found accidentally that there is one, of which I was not aware before, for '.ua.ca' domain - whatever that may be. It dumps you to redirectf.dnsix.com (66.150.161.135 and few other IPs).
Michal
On Fri, 2003-09-26 at 15:28, Michal Jaegermann wrote:
[snip]
A solution turned out to be to explictitely declare a name resolution order to 'winbind lmhosts ....', or whatever that is called, in smb.conf. I do not have Samba here so I cannot check that directive but it is mentioned explicitely in one of 'BROWSING' documents.
If your customer has control of his DNS server and it's running bind, then the delegation-only patch can be applied and then he can list all the gTLDs /etc/named.conf. There may be patches for other DNS servers as well. I applied the patch at www.isc.org and am now happily seeing the normal, non-Verisign corrupted dns behavior. (The version in rawhide is actually a bit outdated. It's 9.2.2-P1 and ISC recommends 9.2.2-P3.) At least until they circumvent it some other way. *sigh*
On Fri, Sep 26, 2003 at 07:22:09PM -0400, Paul Iadonisi wrote:
On Fri, 2003-09-26 at 15:28, Michal Jaegermann wrote:
[snip]
A solution turned out to be to explictitely declare a name resolution order to 'winbind lmhosts ....',
If your customer has control of his DNS server
Stop right here! :-)
and it's running bind,
No, they are not running bind.
then the delegation-only patch can be applied
I was pondering about that possibility, and I would do something of that sort if I would have no other way out, but in this particular situation that would meant other kind of trouble on a long run. It is much healthier if they do not run more than really necessary. :-)
Anyway, my response was just a suggestion that a reported Samba trouble could have similar reasons and it is worth to check that. It also good to keep that in mind if you see something like that yourself. It would definitely gain me some sleep hours ...
Michal
If your customer has control of his DNS server
Stop right here! :-)
Hmm... a number of local ISPs here are considering doing their own fixes a the level of their nameservers. Perhaps you could persuade the client's upstream to do the same thing? It'd probably help their spam filters get back to full performance, too.
Craig Ringer
Latest patch is there.
http://rawhide.redhat.com/pub/redhat/linux/rawhide/i386/RedHat/RPMS/bind-9.2...
Paul Iadonisi wrote:
On Fri, 2003-09-26 at 15:28, Michal Jaegermann wrote:
[snip]
A solution turned out to be to explictitely declare a name resolution order to 'winbind lmhosts ....', or whatever that is called, in smb.conf. I do not have Samba here so I cannot check that directive but it is mentioned explicitely in one of 'BROWSING' documents.
If your customer has control of his DNS server and it's running bind, then the delegation-only patch can be applied and then he can list all the gTLDs /etc/named.conf. There may be patches for other DNS servers as well. I applied the patch at www.isc.org and am now happily seeing the normal, non-Verisign corrupted dns behavior. (The version in rawhide is actually a bit outdated. It's 9.2.2-P1 and ISC recommends 9.2.2-P3.) At least until they circumvent it some other way. *sigh*
-
Craig Ringer -
Daniel J Walsh -
Lon Hohberger -
Michal Jaegermann -
Paul Iadonisi -
Rainer Hattenhauer