<br><br><div class="gmail_quote">On Fri, Jul 15, 2011 at 10:58 PM, <span dir="ltr"><<a href="mailto:gluster1206@akxnet.de">gluster1206@akxnet.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Am 15.07.2011 19:20, schrieb Anand Avati:<br>
<br>
Anand,<br>
<br>
thanks for the quick answer and trackdown.<br>
<div class="im"><br>
> Groups: 8 310 5003 5004 5004 5005 5006 5007 5008 5009 5010 5011 5012<br>
> 5013 5014 5015 5016 5017 5018 5019 5020 5021 5022 5023 5024 5025 5028<br>
> 5029<br>
><br>
> OK, the problem here seems to be that you have > 16 aux groups. The<br>
> protocol in 3.1/3.2 has support for carrying over 16 aux gids to the<br>
> server, which was inherited from NFS' rpc-auth (unix/sys). If your<br>
> application has fewer than 16 secondary groups, it will work fine<br>
> for you. You will see this issue even with NFS.<br>
<br>
</div>The scenerio with that number of groups is not unusual on a server with<br>
shared web hosting, as every customer gets an own group.<br>
<div class="im"><br>
> We plan to bump up this limit in a future version of the protocol.<br>
> But that would break compatibility. While we figure out a workaround<br>
> for your situation, please continue to use 3.2.1.<br>
<br>
</div>I do not completely understand... with 3.2.1, it works. So why doesn't<br>
it work with 3.2.2.<br>
<div><div></div><div class="h5"><br></div></div></blockquote><div><br></div><div>That is because we had to backport posix-acl support to 3.2 series and that has introduced these checks on the server, which would not have been noticable if the aux groups list fitted in the array. We're investigating a work around for such scenarios.</div>
<div><br></div><div>Avati</div></div>