5:58 a.m.
On 8/14/19 12:54 AM, Soumya Koduri wrote:
On 8/14/19 2:35 AM, Erik Jacobson wrote:
>> The only thing I can see is that it tries to open /dev/tty and fails.
>> However, that's very early in the process, and it continues for a
>> long time
>> after that, so I'm not sure that is causing it to fail. It never
>> gets to
>> trying to lookup /home/erikj, it just stops at /home.
>>
>> I'm a bit stumped at this point. Maybe a packet trace of a working
>> run of
>> the same thing would be helpful for comparison?
>
> Hello - Meetings (... bleh)
>
> I re-ran the test using rhel76 - same image as before, same test as
> before same node as before.
>
> I nothing in the gNFS nfs log (but I didn't enable anything verbose
> there).
>
> It worked fine to do the "su - erikj" test as we expected with gNFS.
>
> I have attached a capture to this email. I hope it helps.
>
> I'm starting to look through the output myself but I won't be much use
> at spotting something I'm afraid.
>
> Let me know if you see something in this working case that could be a
> clue! Thank you !!!!
One thing I noticed from this gNFS pkt trace is that after LOOKUP on
"/home", client immediately sent "GETACL" call. Maybe archlinux needs
ACL support for non-root users (just a guess) and as NFS-Ganesha does
not support NFSACL program (it sent "program not supported error to
NFSACL NULL call), it gave "Operation not supported" error.
NFS-Ganesha supports only NFSv4.x ACLs. Could you re-enable ACLs (global
and export level) in the ganesha config and try using NFSv4.x protocol?
Possible, although the successful pcap has NFSACL calls before the
lookup of /home, so that may not be the case. But you're right that the
next thing in the successful pcap is an NFSACL, and the ACCESS call only
comes after that, and the ACCESS call never occurs on the failed pcap.
Note that the NFSACL calls in the gnfs case always return empty ACLs, so
the ACLs aren't being used for anything.
Daniel