On Mon, 2003-08-04 at 00:46, Joshua Peter wrote:
> >The fact that you have
> > the IP's obfuscated
> > makes me wonder if you're running this on a real IP?
>
> Bingo!
>
> Prior to copying and pasting my smb.conf contents, I
> realized that using the SWAT had cleared out a lot of
> my original configurations. I'm confident that this is
> the reason as to why I'm no longer able to see it in
> my Win2k Network Neighborhood. Anyway, the following
> is from my smb.conf file:
>
> # smb.conf file start
> # Samba config file created using SWAT
> # from ops-netw (127.0.0.1)
> # Date: 2003/08/03 19:41:38
>
> # Global parameters
> [global]
> workgroup = PRODSVCS
> netbios name = OPS-NETW
> server string = samba server
> security = DOMAIN
> encrypt passwords = Yes
> obey pam restrictions = Yes
> pam password change = Yes
> passwd program = /usr/bin/passwd %u
> passwd chat = *New*password* %n\n
> *Retype*new*password* %n\n
> *passwd:*all*authentication*tokens*updated*successfully*
> username map = /etc/samba/smbusers
> unix password sync = Yes
> log file = /var/log/samba/%m.log
> max log size = 0
> socket options = TCP_NODELAY SO_RCVBUF=8192
> SO_SNDBUF=8192
> dns proxy = No
> wins server = XXX.XXX.XXX.XXX
> hosts allow = XXX.XXX.XXX.XXX
> printing = cups
I still don't know enough about your setup to help you. You have your
"hosts allow" parameter obfuscated. You haven't described your
network/domain setup. Why is this on a public IP? You realize that
netbeui is non-routable, right? Is this supposed to be acting as a BDC
to an NT PDC? If not, you should be using "security = user". Granted,
this shouldn't stop you from viewing public shares, but it's another
example of a questionable configuration.
This is probably going to require more resources than I can give you via
email. Have you attempted to tcpdump your traffic to verify that the
Samba server is receiving browse requests? Run a "tail -f" on your
logfiles at the same time. Try browsing a share via UNC
("\\ip_address\share_name"), rather than the Netbios name.
The key with any type of troubleshooting, particularly with services
like Samba, is to start at the lowest possible OSI layer and work
upwards. Assuming you have physical connectivity, make sure your
traffic is switched appropriately. Once that is confirmed, run the
tcpdump (or ethereal) to verify that traffic is being received on the
server. Once you've confirmed traffic, see if you're seeing "valid"
traffic (TCP = SYN/ACK/PUSH/ACK/etc., UDP, etc.). Look for early FINs
or RSTs. Once you see what appears to be "normal" traffic, move up to
the application layer.
Look through your Samba logs (/var/log/samba/smbd.log,
/var/log/samba/nmbd.log). Once you see real requests coming in, but
they can't authenticate properly, direct your attention to the
client-specific logs. They will be of the format
"/var/log/samba/<netbios_name>.log". Tail them to see what errors
you're getting.
I know this is a lot of information to absorb, but a proper Samba
configuration is not a matter of right-clicking a folder and choosing
"share". It's working with the smb.conf file by hand (screw SWAT!),
learning the directives, and analyzing the traffic. The O'Reilly Samba
book is a great resource, although the same information can be gleaned
online (http://www.samba.org/samba/docs/) or from the RPM
(/usr/share/doc/samba-2.x.x/docs/). Hopefully this will get you
started.
--
Jason Dixon, RHCE
DixonGroup Consulting
http://www.dixongroup.net
--
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list
