Description of problem: Option nfs.rpc-auth-reject was used to prohibit a client(s) to mount a volume. So the volume mount fails on that prohibited client. Now, a well known command called "gluster volume reset" is used to bring all the "volume set" variables back to default. Still the volume mount fails on the prohibited client, as the client is no more prohibited after using the "reset" command. Version-Release number of selected component (if applicable): glusterfs-3.4.0.53rhs-1.el6rhs.x86_64 How reproducible: always Steps to Reproduce: 1. create a volume, start it 2. set the option, nfs.addr-namelookup to "on" 3. set the ooption, nfs.rpc-auth-reject "client(s) to be rejected" 4. try mount from the prohibited client 5. gluster volume reset <volume-name> 6. repeat step 4. Actual results: step4 --- works as expected, as it does not allow the prohibited client to mount the volume. step 6 ---- fails, as mount operations still fails. volume info after step 3, [root@quota5 ~]# gluster volume info dist-rep Volume Name: dist-rep Type: Distributed-Replicate Volume ID: 4ee792db-48f0-463e-8ad1-d1507d161227 Status: Started Number of Bricks: 6 x 2 = 12 Transport-type: tcp Bricks: Brick1: 10.70.35.219:/rhs/brick1/d1r1 Brick2: 10.70.35.108:/rhs/brick1/d1r2 Brick3: 10.70.35.191:/rhs/brick1/d2r1 Brick4: 10.70.35.144:/rhs/brick1/d2r2 Brick5: 10.70.35.219:/rhs/brick1/d3r1 Brick6: 10.70.35.108:/rhs/brick1/d3r2 Brick7: 10.70.35.191:/rhs/brick1/d4r1 Brick8: 10.70.35.144:/rhs/brick1/d4r2 Brick9: 10.70.35.219:/rhs/brick1/d5r1 Brick10: 10.70.35.108:/rhs/brick1/d5r2 Brick11: 10.70.35.191:/rhs/brick1/d6r1 Brick12: 10.70.35.144:/rhs/brick1/d6r2 Options Reconfigured: nfs.rpc-auth-reject: rhsauto005.lab.eng.blr.redhat.com nfs.rpc-auth-allow: rhsauto002.lab.eng.blr.redhat.com nfs.addr-namelookup: on features.quota: off mount info after step4, [root@rhsauto005 ~]# mount -t nfs 10.70.35.219:dist-rep /mnt/nfs-test mount.nfs: access denied by server while mounting 10.70.35.219:dist-rep volume info after step5, [root@quota5 ~]# gluster volume info dist-rep Volume Name: dist-rep Type: Distributed-Replicate Volume ID: 4ee792db-48f0-463e-8ad1-d1507d161227 Status: Started Number of Bricks: 6 x 2 = 12 Transport-type: tcp Bricks: Brick1: 10.70.35.219:/rhs/brick1/d1r1 Brick2: 10.70.35.108:/rhs/brick1/d1r2 Brick3: 10.70.35.191:/rhs/brick1/d2r1 Brick4: 10.70.35.144:/rhs/brick1/d2r2 Brick5: 10.70.35.219:/rhs/brick1/d3r1 Brick6: 10.70.35.108:/rhs/brick1/d3r2 Brick7: 10.70.35.191:/rhs/brick1/d4r1 Brick8: 10.70.35.144:/rhs/brick1/d4r2 Brick9: 10.70.35.219:/rhs/brick1/d5r1 Brick10: 10.70.35.108:/rhs/brick1/d5r2 Brick11: 10.70.35.191:/rhs/brick1/d6r1 Brick12: 10.70.35.144:/rhs/brick1/d6r2 Options Reconfigured: features.quota: off mount info after step6, [root@rhsauto005 ~]# mount -t nfs 10.70.35.219:dist-rep /mnt/nfs-test mount.nfs: access denied by server while mounting 10.70.35.219:dist-rep Expected results: step6----as after volume reset command, the volume mount should be allowed. Additional info:
This seems to be working as expected. Could you please recheck. I have tested with build 57. Make sure that the hosts are n/w resolvable (getaddrinfo() should PASS) !
The same issue is being worked/tracked on BZ 1102647. Lets close the issue as duplicate of BZ 1102647. Please reopen if you disagree. Thanks, Santosh *** This bug has been marked as a duplicate of bug 1102647 ***
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days