Red Hat Bugzilla – Bug 141008
samba shares in FC3 tempremental/ dont work in home dir when public share
Last modified: 2014-08-31 19:26:58 EDT
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):
184.108.40.206 pre1.3 and also 220.127.116.11
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.
Asks for a password when it shouldnt, even when you enter right
password it then says Share not found
Opening/browsing of share :)
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
path = /home/Downloads
guest ok = Yes
browseable = yes
path = /home/%s
valid users = %S
read only = No
browseable = No
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?
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 18.104.22.168 by the way
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
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?
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.
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.