12:18 p.m.
On 8/14/19 11:24 PM, Erik Jacobson wrote:
> I see NFS4ERR_GRACE errors in the middle. Was nfs-ganesha server
restarted?
> That could be the reason for long pause you see, as NFS server enters into
> grace period (by default 90sec) post restart.
Oh YES!!! That's it on the pause. I forgot about that. So the pause is
solved.
> I see below message in the logs -
>
> 14/08/2019 11:46:32 : epoch 5d543a75 : leader1 : ganesha.nfsd-5581[svc_14]
> fsal_check_access_acl :NFS4 ACL :DEBUG :final access denied (EACCESS)
>
> So you had quoted earlier, maybe this access denial was due to unix
> perms/acls set on that particular file/dir indeed, as the user is getting
> mapped to nobody (4294967294).
So I switched ganesha.conf back to
In global:
Disable_ACL = TRUE;
In EXPORT:
Disable_ACL = TRUE
I re-ran it and don't see the message above any more (no "denied" in
lower case). The test case behaves the same, and I see these instead.
_check_access_no_acl :NFS4 ACL :F_DBG :Mask=0X4000000, Access Type=0X7000000
Allowed=0X4000000 Denied=0X3000000 DENIED
In practical terms, are you saying the directory tree on the nfs server
(on top of gluster) has a permisions problem that is impacting NFS v4
but not NFS v3? Is there something I can do to get around this?
Checked the tcpdump in more detail. "Execute" permission seem to have
got denied for following paths even for root user -
/cm_shared/image/images_ro_nfs/rhel76-aarch64-newkernel/etc/group
/cm_shared/image/images_ro_nfs/rhel76-aarch64-newkernel/usr/share/zoneinfo/America/Chicago
Whereas in case of gNFS pkt trace, root user had Execute access.
I am not sure why there is a difference here anf if this caused issue.
Could you cross check the perms on both mount point and at the backend
bricks path?
Thanks,
Soumya
> Thanks again for looking at the logs once again.
>
> Erik
> _______________________________________________
> Devel mailing list -- devel(a)lists.nfs-ganesha.org
> To unsubscribe send an email to devel-leave(a)lists.nfs-ganesha.org
>