Bug 121744 - other computers can still access share after it has been unshared
Summary: other computers can still access share after it has been unshared
Alias: None
Product: Fedora
Classification: Fedora
Component: redhat-config-samba   
(Show other bugs)
Version: 1
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Brent Fox
QA Contact:
Keywords: Security
Depends On:
TreeView+ depends on / blocked
Reported: 2004-04-27 07:18 UTC by moonwalker
Modified: 2007-11-30 22:10 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-06-24 20:48:15 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 moonwalker 2004-04-27 07:18:22 UTC
Description of problem:

Version-Release number of selected component (if applicable):
Samba Server Configuration Tool 1.1.4

How reproducible:

Steps to Reproduce:
1.create a share
2.access it from another machine
3.remove share

Actual results:
access attempts still successful. can still open subdirectories and
copy files from the share

this was tested in readonly mode

Expected results:
share should cease to be accessable

Additional info:

fedora core 1, clean install, all updates from channel fedora-core-1
from  http://download.fedora.redhat.com/pub/fedora/linux/core/1/i386/os/
as of 04.27.2004

win xp pro sp1

Comment 1 Mark J. Cox 2004-05-06 09:46:56 UTC
Can you give details on what you did in step 3 "remove share"; did you
restart samba?

Comment 2 moonwalker 2004-05-06 11:35:19 UTC
did not restart samba. simply removed share via redhat-config-samba. 
this apears to reside with the tool itself because ive since moved to 
swat and the shares stop access as soon as i disable or remove them 
via swat. also i noticed redhat-config-samba making changes to the 
smb.conf file while in security setting that were unralated to the 
settings i was changing. i had to go back with swat and remedy the 

such as guest being constantly mapped to "nobody" even though i set 
it to no guest account last time.

try it on a fresh fc1 machine with all updates youl find its VERY 

Comment 3 moonwalker 2004-05-06 11:39:00 UTC
actually i take that back - i also tryed restarting samba after the 
changes to no avail - i did not monitor the changes to smb.conf so i 
didnt notice whether or not it was successfully removed from the file 
or not

Comment 4 Brent Fox 2004-05-06 20:07:52 UTC
Mark: redhat-config-samba will restart the smb daemon every time a
change is made, so it shouldn't be necessary for the user to manually
restart the service.

moonwalker: It would be helpful if you could attach an smb.conf file
before and after using redhat-config-samba so I can try to determine
exactly what is being changed in the file.  Also provide the exact
steps that you took to make the changes with the user interface.

Comment 5 moonwalker 2004-05-07 05:05:48 UTC
unfortunately this is a production server slated to go online in 7 
days. ive just learned to stay away from redhat-config-samba for now. 
if i get some time and get it ready for active duty ahead of schedule 
then ill go back and reproduce the error in detail.

the thing i noticed it changing is guest access parms mostly.

Comment 6 Brent Fox 2004-06-24 20:48:15 UTC
The bug with the guest account getting reset to "nobody" is a dupe of
bug #121745 and is fixed in system-config-samba-1.2.11-1.

I am not able to reproduce the problem with the share still being
accessible after it's been deleted from system-config-samba.  I'm
running system-config-samba-1.2.12-1 on an FC2 box and the client is a
RHEL3 AS system.  I don't have a Windows box handy to try that.  

Since I'm not able to reproduce this problem, I'm going to close as
'worksforme'.  Please reopen if you see the behavior on an FC2 machine.

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