Bug 6121 - Samba shares nonfunctional in 6.1?
Summary: Samba shares nonfunctional in 6.1?
Keywords:
Status: CLOSED DUPLICATE of bug 8385
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: installer
Version: 6.1
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jay Turner
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 1999-10-20 04:54 UTC by jered
Modified: 2015-01-07 23:38 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2000-02-08 18:33:13 UTC
Embargoed:


Attachments (Terms of Use)

Description jered 1999-10-20 04:54:32 UTC
It seems more likely that I am a bozo, however Samba shares
appear to fail in my new RedHat 6.1 install.  The machine
does not appear in the browse list for the workgroup on
local windows machines...however it *can* act as the master
browser! Thus samba can play nice to some degree, but for
some reason isn't announcing itself as having available
shares.

I'll admit that I am no samba expert, however this has
stumped me and friends with more samba experience for
several days.

Could you please verify that samba is in fact functional in
6.1? If it is I can send further details, or just go bang my
head against a wall until something new occurs to me. :-)

--Jered
jered

Comment 1 Bill Nottingham 1999-10-20 14:19:59 UTC
Do you have 'remote announce' set in /etc/smb.conf,
as well as having shares marked as 'browseable'?

Comment 2 jered 1999-10-20 16:14:59 UTC
Those shouldn't be necessary, but I have tried adding both
"browseable = yes" and "remote announce = 4.255.0.63" (our network
broadcast address) to no avail. The machine's name is sound-and-fury,
with a CNAME of music, and it's netbios name is set to 'music'. The
nmbd dump when it is acting as a master browser:
   dump workgroup on subnet       127.0.0.1: netmask=      255.0.0.0:
        FLAME(1) current master browser = MUSIC
                MUSIC 40049a03 (Samba 2.0.5a)
                CINDERS 40059203 ()
                FLAMETONGUE 40039003 ()

Relevant bits of smb.conf:
[global]
   workgroup = FLAME
   browseable = yes
   remote announce = 4.255.0.63
   netbios name = MUSIC
; let's try being master browser
   os level = 33

[music]
   comment = Music archive
   path = /music
   guest ok = yes
   printable = no

We don't have any SMB network filters in place, so you're welcome
to try to access the machine...it's name is sound-and-fury.grey17.org,
address 4.255.0.43.

Comment 3 Bill Nottingham 1999-10-20 16:43:59 UTC
Can you mount the share directly from the windows, without going
through the browser?

Comment 4 Bill Nottingham 1999-10-20 16:46:59 UTC
Also, do you have a) a valid guest account (if not specified, it
should be 'nobody' on the Linux box), and b) a WINS server?

Comment 5 Bill Nottingham 1999-10-20 17:21:59 UTC
Also, I could have sworn that 4.255.0.x isn't a valid IP address.

Comment 6 jered 1999-10-20 17:57:59 UTC
Curiously, I've heard that from others in the past...what reason do
you have to think that 4.255.0.x would not be valid? I've found that
the 255 and the 0 both confuse people who aren't used to seeing those
numbers in IP addresses.  Rest assured, it is valid, you're welcome to
try to ping or otherwise inspect any of my machines (but alas they're
not exporting much interesting.)

As for the other questions:
The guest account is not set and thus should default to nobody. This
is a fresh 6.1 install and su'ing to nobody, I can read the files in
the shared directory. I've also tried explicitly setting the guest
user to 'nobody'; this didn't help.

We do not have a WINS server.

earlier I would have said that i couldn't mount at all from a windows
machine, but now I am trying from work and seeing an odd response. Is
there something special I need to do to tell windows to try to mount a
share as guest? Right now, when I:
net use \\sound-and-fury.grey17.org\music /USER:guest

I get:
The password is invalid for \\sound-and-fury.grey17.org\music.
Type the password for \\sound-and-fury.grey17.org\music:
System error 86 has occured.

The specified network password is not correct.

And in my smb log:
[1999/10/20 13:52:01, 3] smbd/reply.c:reply_sesssetup_and_X(721)
  Domain=[AI.MIT.EDU]  NativeOS=[Windows NT 1381] NativeLanMan=[]
[1999/10/20 13:52:01, 3] smbd/reply.c:reply_sesssetup_and_X(725)
  sesssetupX:name=[guest]
[1999/10/20 13:52:01, 3] smbd/error.c:error_packet(138)
  error packet at line 840 cmd=115 (SMBsesssetupX) eclass=2 ecode=2
[1999/10/20 13:52:01, 3] smbd/error.c:error_packet(143)
  error string = No such file or directory
[1999/10/20 13:52:01, 3] smbd/process.c:timeout_processing(828)
  end of file from client
[1999/10/20 13:52:01, 2] smbd/server.c:exit_server(406)
  Closing connections
[1999/10/20 13:52:01, 3] smbd/server.c:exit_server(433)
  Server exit (normal exit)

Oddly, if I try to do a:
net use \\music.grey17.org\music

I get:
System error 53 has occured.

The network path was not found.

Comment 7 jered 1999-10-20 18:15:59 UTC
Aha. I've found that I can access the share from smbclient if I do:
smbclient '\\MUSIC.GREY17.ORG\MUSIC' -U ''

And it will use the guest account and access the share. Am I
misunderstanding how samba shares are supposed to work? All i want is
a publicly readable share that anyone can access. I can't seem to find
a way to let Windows see this.

Comment 8 Bill Nottingham 1999-10-20 19:50:59 UTC
If you're connecting from NT or 98 for a named account, you
have to make sure that you have the correct settings for
password encryption.

Are the Windows machines you're trying to use using wins
at all?

------- Additional Comments From   10/23/99 17:41 -------
I've solved the problem. Half of the problem was a change in the
default Samba config between versions, and half was a rather serious
bug in the 6.1 installer, I think.

The easy one first: The reason that I couldn't attach shares as guest
was because I had 'security = user'. For anonymous shares, I need
'security = share'. At some point, the default Samba config changed
from share to user.  'user' security is probably more useful to the
majority of Samba users anyway.

Now, the RedHat bug. The reason that the Samba server could not
properly participate in the browse list was because the 6.1 installer
creates an incorrect /etc/hosts:
127.0.0.1               localhost.localdomain localhost
sound-and-fury.grey17.org
4.255.0.43              localhost.localdomain

This is wrong in at least two ways.  The Samba server resolves its
FQDN to 127.0.0.1 and reports to the browse list that it can be
reached at that address, which is of course wrong. A proper /etc/hosts
solves this problem:
127.0.0.1       localhost
4.255.0.43      sound-and-fury.grey17.org sound-and-fury music

Could you please find out why the 6.1 install process creates this
bogus /etc/hosts?

Thanks for your help in debugging this!

Comment 9 jered 1999-10-23 22:24:59 UTC
FYI, Bug #5967 is a duplicate of the second bug.

Comment 10 Geoff Reedy 1999-12-14 06:43:59 UTC
If you have security level set to user there are some special things
that need to be done for access to guest shares.  This is because
with user security mode, the client needs to authenticate before
telling the server what share it is requesting.  Because of this
even though the share is a guest share the person connecting still
needs to know a valid login and password.  To get around this set
map to guest to either Bad password of Bad username, check the
smb.conf manpage to figure out which is best for your situation.
As far as browsing is concerened try setting local master to yes
as the windows NMB implementation is too braindead to be the LMB.

Comment 11 Jay Turner 2000-02-08 18:33:59 UTC
This is a known bug that we are working on at the moment.  The reason for the
/etc/hosts in the format that you see it is because of laptop users who need to
be able to resolve a hostname after removing their NIC, or leaving the network.

We are trying to determine the best way to handle the various situations.

*** This bug has been marked as a duplicate of 8385 ***


Note You need to log in before you can comment on or make changes to this bug.