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.
~ Jeff Byers ~
*** This bug has been marked as a duplicate of bug 4264 ***