12:40 a.m.
I couldn't find any errors in pkt trace or logs. This was the last
request to server -
2435 2019-08-13 00:50:57.109745 172.23.0.16 172.23.255.249 NFS 190 V3
LOOKUP Call (Reply In 2436), DH: 0x14a68d9b/home
2436 2019-08-13 00:50:57.111669 172.23.255.249 172.23.0.16 NFS 318 V3
LOOKUP Reply (Call In 2435), FH: 0x6bc807c0
/home permissions returned are 0755
and '/' has 0555
Maybe there is something else blocking the user. I am not much familiar
with aarch64 or overlayfs. Could you check if there are any errors
(maybe from selinux or similar) in system logs.
I found some old thread with similar issue reported [1]. Could you check
permissions of 'ls -la /'
Thanks,
Soumya
[1] https://bbs.archlinux.org/viewtopic.php?id=154628&p=2
On 8/13/19 1:06 AM, Erik Jacobson wrote:
> OK. Here is what I did.
>
> - Note: I have the test system setup in this test case so I can re-run
> it easy no problems.
>
> - I added a shellout in our 'miniroot' environment to give me a shell
> right after it made the overlay mount to /a (/a is what becomes root).
>
> - I did this *before* the "--move" lines we do to make switch_root happy
> just in case (same result).
>
> - I had it pause waiting for me to hit ENTER before doing the mount.
> That way, I started the captures and cleared the logs right before
> hitting ENTER and then stopped capture and ganesha right after the
> test.
>
> - I captured all traffic between leader1 (the ganesha server) and
> n2521 (the aarch64 compute node).
> - compute node IP: 172.23.0.16
> - leader main ip: 172.23.0.3
> - CTDB-managed IP alias (compute node mounts from there): 172.23.255.249
>
> - I captured all traffic between leader one and the other 8 leaders
> but excluded nfs and ctdb. I was concerned if I restricted just to nfs
> and gluster I'd miss a port. I am happy to re-run the test
> differently.
>
> - I attached an xz-compressed tarball.
>
> - Content:
> ganesha.conf (With the suggested way to disable ACL)
> ganesha-gfapi.log
> ganesha.log
> gluster-brick-log-readme.txt (a sample and a remark that all were
> about the same)
> leaders-no-ctdb-no-nfs.pcap (capture among compute nodes)
> n2521.pcap (capture between leader/nfs server and compute node)
> node-output.txt (output from the failing "su" command on the problem
node)
> tcpdump-cmd-lines-readme.txt (How I did the capture, how to read)
>
>
> - I game to try anything that can help resolve this. I really appreciate
> your time so far. I wish I could be more helpful on my end.
>
> Erik
>
>
> _______________________________________________
> Devel mailing list -- devel(a)lists.nfs-ganesha.org
> To unsubscribe send an email to devel-leave(a)lists.nfs-ganesha.org
>