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): 3.0.8.0 pre1.3 and also 3.0.9.0 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 smb://user:pass@linuxpc/share 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 [global] 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 [1] 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 [2] path = /home/Downloads guest ok = Yes browseable = yes [homes] 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?
Hi, 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 3.0.9.1 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 https://bugzilla.samba.org
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? cheers crunchie
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!
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.