Although a configuration change to 'smb.conf' when adding a share, or changing many of the options is well handled by reloading the conf file with "smb reload", the common cases of deleting or renaming a share are not. Sessions to the old names continue to function. The only way to affect the changes when the share is being deleted or renamed is to do a full "smb restart" which of course impacts the operation of all shares. This is the case for versions 4.1.4 and 3.6.12.
Have you seen the smbcontrol close-share and reload-config commands? You should be able to first disable the share in the config, then use reload-config and finally close-share
(In reply to comment #1) > Have you seen the smbcontrol close-share and reload-config commands? > > You should be able to first disable the share in the config, then use > reload-config and finally close-share Thanks Christian. I've thought about it some, and it seems the procedure would need to be, like you said: 1) Change the share's "available = no". 2) Have Samba reload the conf with "smb reload". 3) Obtain the active sessions for the share using "smbstatus -S". 4) For each session, disconnect it using "smbcontrol close-share". 5) Rename or delete the share completely from smb.conf. 6) Reload the conf again with "smb reload". I would still wonder if there was something about the deleted Samba share still in memory though. I guess I could test that by creating a new share under the same name to see if there was anything strange happening with it. BTW, it would sure be nice if there was a wild-card for "smbcontrol close-share" to close all sessions instead of one at a time. There is a "*" wild-card for all services, but apparently not or all sessions, so they need to be obtained, and acted upon one at a time. Thanks again. ~ Jeff Byers ~
*** This bug has been marked as a duplicate of bug 4264 ***