<div dir="ltr"><div dir="ltr">Hi Strahil,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 10 Feb 2020 at 15:28, Strahil Nikolov <<a href="mailto:hunter86_bg@yahoo.com">hunter86_bg@yahoo.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Alberto,<br>
Sadly you should verify if the issue is the same.<br>
Enable the trace logs for the bricks and verify if the errors in the logs with those in the bugzilla.</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Don't forget to stop the trace log or your logs' dir will get full.<br></blockquote><div><br></div><div>Yes, the log is quite similar:</div><div><br></div><div><span style="font-family:monospace">[2020-02-10 10:38:17.402080] I [MSGID: 139001] [posix-acl.c:263:posix_acl_</span><span style="font-family:monospace">log_permit_denied] 0-app_data-access-control: client: CTX_ID:7d744c50-43a1-4f81-</span><span style="font-family:monospace">9330-001b5dcaddb7-GRAPH_ID:0-</span><span style="font-family:monospace">PID:2310-HOST:ast10.local.</span><span style="font-family:monospace">domain-PC_NAME:app_data-</span><span style="font-family:monospace">client-1-RECON_NO:-1, gfid: 092f1e28-d6a8-4ca9-95d5-</span><span style="font-family:monospace">75dc8ad1c835, req(uid:498,gid:498,perm:4,</span><span style="font-family:monospace">ngrps:1), ctx(uid:0,gid:0,in-groups:0,</span><span style="font-family:monospace">perm:000,updated-fop:INVALID, acl:-) [Permission denied]</span></div><div><font face="monospace">[2020-02-10 10:38:17.402182] E [MSGID: 115056] [server-rpc-fops_v2.c:687:server4_opendir_cbk] 0-app_data-server: 6257941: OPENDIR /mailboxes.old/8692/211411002/Old (092f1e28-d6a8-4ca9-95d5-75dc8ad1c835), client: CTX_ID:7d744c50-43a1-4f81-9330-001b5dcaddb7-GRAPH_ID:0-PID:2310-HOST:ast10.local.domain-PC_NAME:app_data-client-1-RECON_NO:-1, error-xlator: app_data-access-control [Permission denied]</font><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
What version of gluster are you using ?<br></blockquote><div><br></div><div>Gluster 6.6.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
In my case only a downgrade has restored the operation of the cluster, so you should consider that as an option (last, but still an option).<br>
<br></blockquote><div><br></div><div>We created a copy of the faulty's directory and put it in place of the older one to solve our issues for now. We kept the old one for further investigation. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
You can try to run a find against the fuse and 'find /path/to/fuse -exec setfacl -m u:root:rw {} \;'<br>
Maybe that will force gluster to read the ACLs again.<br></blockquote><div><br></div><div>Running a setfacl doesn't make any difference. If we do a chmod it "fixes" the permission problem. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Good luck!<br>
If you have the option, join the next gluster meeting and ask for an update (if the issue is actually the same).<br>
<br>
Best Regards,<br>
Strahil Nikolov<br></blockquote><div><br></div><div>Thank you,</div><div>Alberto Bengoa </div></div></div>