On 6/13/14 1:08 PM, Niels de Vos wrote:
On Fri, Jun 13, 2014 at 09:56:46AM +0200, Ivano Talamo wrote:I had done it only on one of the two :( But even after I've done it on the other server and I've restarted the gluster daemon I see no changeCan you confirm that the issue is still occurring after you stopped and restarted the volume? A restart of the volume is needed to activate the server.allow-insecure volume option. When that option is not active, the glusterfs-client (libgfapi) will not be able to connect to the bricks. The bricks will detect that the client uses a port > 1024 an does not allow access. With a stop and start of the volume, the .vol files that are used by the brick processes get regenerated. With this regeneration, the server.allow-insecure option gets activated correctly. You only have to execute these commands on one storage server: # gluster volume stop <volname> # gluster volume start <volname> This is one of the most common issues when using libgfapi. If this indeed was not done in your environment, we may need to explain it better, or make it more obvious in the documentation.
I restarted only the glusterd service, not the volume. At the moment I cannot stop the volume since is mounted and in production. I will do it after 17 UTC or tomorrow at most and will update you then. Thanks, Ivano
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Gluster-users mailing list Gluster-users@xxxxxxxxxxx http://supercolony.gluster.org/mailman/listinfo/gluster-users
