9:56 a.m.
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.
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