On 8/14/19 10:26 PM, Erik Jacobson wrote:
I have attached an xz-9 tar. The collections are bigger largely becaused of as secondary issue where the "chroot /a" step takes a long long time.
I kept nfs debugging enabled for this. I put details on the collection, output, and other stuff in the tarball.
FWIW the nfs v3 doesn't suffer from the strange UID problem. The UIDs/GIDs are all good there. This is only experienced with NFS v4 and from both architectures.
x86_64 fully boots fine, as we discussed earlier, with nfs v3 ganesha.
Thank you !! out2.tar.xz is attached.
Is this tcpdump of the simplified test case (i.e, su - erikj)? There are no lookups on /home directory this time (may be the process havent reached that point yet). 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. 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). Thanks, Soumya
Best wishes,
Erik
On 8/14/19 9:41 PM, Erik Jacobson wrote:
Soumya - got your note, I'll get that started.
An fyi that, in this case, x86_64 & nfs v4, has the same behavior as aarch64. That is, x86_64 fails too for nfs v4 with this UID/GID thing.
I would assume that at least you got past with arch linux distro issue with no acls. The error now could have been because of EACCESS returned by ganesha/gluster server and hence the same behavior on both the distros.
Some how the IDs are rolling. Is my setup wrong?
As I mentioned earlier, nfs-ganesha server switches to the nfs client user creds before performing any operations on backend gluster server. There may be some operation denied by the server. Tcpdump may give some clue. Until we root cause the issue, cannot comment if this can(/not) be fixed.
Thanks, Soumya
I'll work on the traces/logs.
sh-4.2# ls -l /etc/securetty -rw------- 1 4294967294 4294967294 221 Jun 21 2018 /etc/securetty
_______________________________________________ Devel mailing list -- devel@lists.nfs-ganesha.org To unsubscribe send an email to devel-leave@lists.nfs-ganesha.org