Red Hat Bugzilla – Bug 1001102
Stale smb share still shows up after deleting the gluster volume
Last modified: 2015-12-03 12:11:07 EST
Description of problem:
Stale smb share still shows up after deleting the gluster volume on rhs node.
But restarting the smb i.e. "service smb restart" fixes the issue.
Version-Release number of selected component (if applicable):
root@bvt-rhs1 ~]# rpm -qa | grep samba
[root@bvt-rhs1 ~]# rpm -qa | grep gluster
Steps to Reproduce:
1.Create a gluster volume and start it
2. on the windows client(win7) verify the samba share is visible and accessible i.e. \\<server ip>
3.stop the gluster volume and delete it
gluster v stop testvol
gluster v delete testvol
4. Check if the volume is still shows up as samba share in windows client i.e. \\<server ip>
The stale entry of samba share will be visible, though it will be not be accessible
After deleting the samba share of rhs volume, should not be visible.
After deleting the volume, I verified that smb.conf didn't have any entry for the corresponding volume.
Try the following command:
smbcontrol all reload-config
When run from the root account, that command should cause all Samba daemons (including winbindd) to immediately reload the smb.conf configuration files.
Note that the Samba daemons will eventually reload the configuration file on their own, but it may be a minutes before the automatic reload occurs.
"smbcontrol all reload-config" works fine. May be hook script change will do the job.
Is there any smb.conf parameter which does this job of reading smb.conf file ?
Currently in the hook script we are sending a SIGHUP to smbd daemon.
But for windows client to reload the smb.conf we have to send SIGHUP to winbindd ,which I think will fix this issue.
I tested the for SAMBA+XFS just to confirm that whether glusterfs plays any role in it. And I am finding the same issue of stale shares.
And "smbconbtrol all reload-config" doesn't work always.
I think the reloading of smb-conf is confined to the smbd process only and the client does not go for refresh.
I think we can document the above findings if needed.
Also we observe that, when the gluster volume is stopped, the "smbclient -L" does not show any entry for the volume stopped, but the volume still continues to appear in the windows client.
I filed a bug in SAMBA Bugzilla for this.
Here is the link : https://bugzilla.samba.org/show_bug.cgi?id=10156
Their resolution is ---> restart smbd.
See if this will help:
The command in question is "smbcontrol close-share", and should be done BEFORE the volume is stopped. Note the concerns that the email author brings up, but I don't think they impact us.
Thank you for submitting this issue for consideration in Red Hat Gluster Storage. The release for which you requested us to review, is now End of Life. Please See https://access.redhat.com/support/policy/updates/rhs/
If you can reproduce this bug against a currently maintained version of Red Hat Gluster Storage, please feel free to file a new report against the current release.