Bug 10485 - "smb reload" does not handle deleted or renamed shares.
"smb reload" does not handle deleted or renamed shares.
Status: RESOLVED DUPLICATE of bug 4264
Product: Samba 4.1 and newer
Classification: Unclassified
Component: File services
4.1.4
All All
: P5 normal
: ---
Assigned To: Samba QA Contact
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-03-06 21:48 UTC by Jeff Byers
Modified: 2014-07-01 10:35 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jeff Byers 2014-03-06 21:48:55 UTC
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.
Comment 1 Christian Ambach 2014-03-13 21:35:27 UTC
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
Comment 2 Jeff Byers 2014-03-18 16:18:47 UTC
(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 ~
Comment 3 Björn Jacke 2014-07-01 10:35:09 UTC

*** This bug has been marked as a duplicate of bug 4264 ***