Fix bug #9733 - smbcontrol close-share is not working.

As part of forcibly disconnecting a client from a share,
smbd must atomically call reload_services() to ensure that
the entry in the ServicePtrs[] array corresponding to
that share is removed if the share was removed from
the smb.conf or registry entries.

Otherwise the ServicePtrs[] array entry for the share
remains active and the client races to auto-reconnect to
the share before a second message to reload the smb.conf
file can be sent.

This has to be done as part of the close-share message
processing, as removing the share from the smb.conf file
first, then telling the smbd to reload followed by the
forcible disconnect message doesn't work as in this
sequence of events when the reload message is received
the client is still connected to the share, so the
ServicePtrs[] entry is still left active.

The forcible-disconnect + service reload has to be done
together as an atomic operation in order for this to work.

Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: David Disseldorp <ddiss@samba.org>
Autobuild-User(master): David Disseldorp <ddiss@samba.org>
Autobuild-Date(master): Fri Mar 22 20:10:11 CET 2013 on sn-devel-104

diff --git a/source3/smbd/conn_idle.c b/source3/smbd/conn_idle.c
index 916a2067ad9aeb7ea4e3a273cefb0f1241211d1e..238b7bd76901ef4324db85e089e173050069c302 100644 (file)
--- a/source3/smbd/conn_idle.c
+++ b/source3/smbd/conn_idle.c
@@ -142,4 +142,7 @@ void conn_force_tdis(struct smbd_server_connection *sconn, const char *sharename
 
                TALLOC_FREE(tcon);
        }
+
+       change_to_root_user();
+       reload_services(sconn, conn_snum_used, true);
 }