10:35 a.m.
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(a)lists.nfs-ganesha.org
> To unsubscribe send an email to devel-leave(a)lists.nfs-ganesha.org
>