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@lists.nfs-ganesha.org To unsubscribe send an email to devel-leave@lists.nfs-ganesha.org