Red Hat Bugzilla – Bug 1107606
Setting either of user.cifs or user.smb option to enable leads to enabling of smb shares. Enable only when none are disable
Last modified: 2015-05-13 13:41:04 EDT
+++ This bug was initially created as a clone of Bug #1105147 +++ Description of problem: We have two volume options, user.cifs and user.smb which are considered valid keys for enabling/disabling of smb shares. user.smb was introduced later and user.cifs is maintained for backwards compatibility. The approach taken is disable has more weightage than enable. If either of the two keys have value as disable then the combined effect is that of disable. Start and stop volume hookscripts work as per above approach. Set option hookscript does not. This leads to a inconsistent behaviour. Version: How reproducible: Always Steps to Reproduce: 1. gluster volume set volname user.cifs disable 2. smbclient -L localhost check that share related to volume is not available. 3. gluster volume set volname user.smb enable 4.smbclient -L localhost Actual results: smbclient output shows that share related to this volume is available. Expected results: smbclient output should not have share related to this volume. Additional info:
What we SHOULD have is user.cifs being deprecated and user.smb as a synonym for user.cifs. That is, they are both actually the same option. Or, if that is technically a problem, just have either one update both options, such that user.cifs and user.smb are ALWAYS identical and thus there would be no question about the state of SMB shares for that volume.
Yup, that is the right way of doing things. To do that we need to change the code in glusterd. Targeting it for next release.
Patch posted at https://code.engineering.redhat.com/gerrit/#/c/36686/
After disabling user.cifs for the volume,the samba share still exists in smb.conf. Even if we disable user.smb still teh samba share exists in smb.conf. Volume Name: verify-vol Type: Distributed-Replicate Volume ID: 201ca6bc-5693-40aa-bd2f-6c9767225fa5 Status: Started Snap Volume: no Number of Bricks: 2 x 2 = 4 Transport-type: tcp Bricks: Brick1: 10.16.159.81:/rhs/brick1/verify-vol/b1 Brick2: 10.16.159.63:/rhs/brick1/verify-vol/b2 Brick3: 10.16.159.81:/rhs/brick1/verify-vol/b3 Brick4: 10.16.159.63:/rhs/brick1/verify-vol/b4 Options Reconfigured: user.smb: disable user.cifs: disable testparm: [gluster-verify-vol] comment = For samba share of volume verify-vol path = / read only = No guest ok = Yes vfs objects = glusterfs glusterfs:loglevel = 7 glusterfs:logfile = /var/log/samba/glusterfs-verify-vol.%M.log glusterfs:volume = verify-vol Version: glusterfs-server-3.6.0.33-1.el6rhs.x86_64 Moving the BZ back to Assigned.And this also hits regression where even with disabling one of the options the share is not getting removed from smb.conf.
Patch posted at https://code.engineering.redhat.com/gerrit/#/c/37464/
Verified the BZ with build glusterfs-3.6.0.35-1.el6rhs.x86_64. Now setting one of the option user.cifs/user.smb to disable removes the share from smb.conf. Verified with following combinations: user.smb ,user.cifs : Both enabled : share is present in smb.conf user.smb , user.cifs : Both disabled : share is removed from smb.conf User.smb :enabled , user.cifs : disabled : share is removed from smb.conf user.smb :disbaled , user.cifs : enabled : share is removed from smb.conf. Also if one of these options is disabled, even with stop and start or start force : share will not be present in smb.conf. Moving the BZ to verified.
Raghavendra, Please review the edited doc text and sign-off.
The doc text looks good to me.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2015-0038.html