Bug 141008 - samba shares in FC3 tempremental/ dont work in home dir when public share
Summary: samba shares in FC3 tempremental/ dont work in home dir when public share
Alias: None
Product: Fedora
Classification: Fedora
Component: samba   
(Show other bugs)
Version: 3
Hardware: All Linux
Target Milestone: ---
Assignee: Jay Fenlason
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2004-11-28 01:44 UTC by crunchie
Modified: 2014-08-31 23:26 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-10-31 20:35:23 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description crunchie 2004-11-28 01:44:52 UTC
Description of problem:

Samba shares seem tempremental or dont work at all, when a samba share
is linked to a home directory. e.g /home/user/shared

All other shares work but any share made in a home dir does not work
when set to a guest/public share and is very tempremental when logging
 into the samba share with the user/password as well.

For 10minutes earlier it was working with one public share in my home
dir, but not another, the samba settings were identical for each share
and the folders had the same chmod and user settings.

Then suddenly both public shares stopped working and havent since :(

Version-Release number of selected component (if applicable): pre1.3 and also

How reproducible:

Every time so far for me, even tried a clean install of FC3 final

Steps to Reproduce:
1. in smb.conf set guest account = nobody and/or use smbpassword
username  to add a password for your loginname

(User nobody does not require password)

2. make a folder within home dir e.g /home/user/share and add to smb.conf

3. enable guest permissions for the folder in samba conf

4. try and view share from remote pc either via 
or as a guest   smb://linuxpc/share  or smb://nobody://linuxpc/share

or, try and view share locally with smb://linuxpc/share   usually says
share not found.

Actual results:
Asks for a password when it shouldnt, even when you enter right
password it then says Share not found

Expected results:

Opening/browsing of share :)

Additional info:

This samba conf should allow any guest to view all shares, even when
they type an incorrect password.

In my situation share 1 doesnt work (did briefly) share 2 does work
fine as do any other shares not within home dir.

# Global parameters
    security = SHARE
    auth methods = guest
    map to guest = Bad Password
    null passwords = Yes
    ldap ssl = no
    hosts allow = 192.168.8.
    guest account = nobody

#share 1 wont work with guest OR user/pass, sometimes randomly does work
    path = /home/crunchie/pub
    guest ok = Yes
    browseable = yes

#Share 2 works fine without a password as a guest and also works with
#a user:password

    path = /home/Downloads
    guest ok = Yes
    browseable = yes

    path = /home/%s
    valid users = %S
    read only = No
    browseable = No

Comment 1 Jay Fenlason 2004-11-29 22:06:56 UTC
Security=share does not deal well with the concept of users.  It's 
pretty much only used for compatability with old Windows versions.  
Can you try configuring samba to use security = user? 

Comment 2 crunchie 2004-11-29 22:13:46 UTC
I tried initially with security = user and only changed it to share to
try and find the source of the problem myself so it had no effect :(

I have it set back to user at the moment and at this time its not
working, but randomly it does seem to work.

since reporting I found that if i make a second shared directory
within my home user space then the first shared dir never allows
guest/user access but the second dir suddenly does. Then if i remove
the share from the first dir, the second stops working again so
something odd is going on.

Other people in #fedora on freenode also seem to have this problem.
At the moment i am running with v by the way

Comment 3 Jay Fenlason 2004-11-29 22:28:20 UTC
I've been unable to reproduce the problem on my rawhide box--I did 
have trouble writing to the shares until I remember that they 
default to read-only unless you include "writable = yes" in the 
configuration stanza, but the shares were always visible in the 
explorer window on my Win-2K client. 
Can you try the 3.0.9-1.3E rpms I just released?  If you're using 
the rpms from samba.org, you should be using the Samba bugzilla at 

Comment 4 crunchie 2004-12-01 14:34:06 UTC
I tried the rpms you just released and it now works stable now for the
home-owner to login and access the home dir, but Guests are still
denied access to any guest share made within home/user directory.

I just reinstalled FC3 to try again and it is still working fine for
users that log in but guests are still denied access.

Could you please post your smb.conf so i can try with an identical
setup to yours.

Have you modified the smbpasswd list for user nobody or added  a guest
user to the fedora user/group list?



Comment 5 Matthew Miller 2006-07-10 20:43:24 UTC
Fedora Core 3 is now maintained by the Fedora Legacy project for security
updates only. If this problem is a security issue, please reopen and
reassign to the Fedora Legacy product. If it is not a security issue and
hasn't been resolved in the current FC5 updates or in the FC6 test
release, reopen and change the version to match.

Thank you!

Comment 6 John Thacker 2006-10-31 20:35:23 UTC
Closing per lack of response to previous request for information.
This bug was originally filed against a much earlier version of Fedora
Core, and significant changes have taken place since the last version
for which this bug is confirmed.

Note that FC3 and FC4 are supported by Fedora Legacy for security
fixes only.  Please install a still supported version and retest.  If
it still occurs on FC5 or FC6, please reopen and assign to the correct
version.  Otherwise, if this a security issue, please change the
product to Fedora Legacy.  Thanks, and we are sorry that we did not
get to this bug earlier.

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