Dear NFS folks,
On 05/16/17 13:06, Paul Menzel wrote:
With Linux 4.9.x there are issues, that the NFSD servers denies access
to NFS mounts. Other clients can still connect fine. A restart of the
*client* fixes the issue.
We believe that this is related to a restart of a NIS server, and that
NFSD is now unable to authenticate the requests. Maybe some cache
mismatch of some client identifications?
```
root:sigchld:~/# mount -v -t nfs hopp:/home/joey /mnt
mount.nfs: timeout set for Tue May 16 12:57:04 2017
mount.nfs: trying text-based options
'vers=4,addr=141.14.25.186,clientaddr=141.14.16.120'
mount.nfs: mount(2): Permission denied
mount.nfs: access denied by server while mounting hopp:/home/joey
```
Could you please point me to the right direction, how this issue can be
debugged?
A first step would be to get debug messages from NFSD, why exactly the
permission was denied to mount the directory.
It turns out, this particular issue was indeed a NIS issue, that the
client wasn’t in the netgroup anymore. So, I am sorry for the noise.
With Wireshark we were able to find the NFSD response `Bad credentials
(seal broken)`, leading us in the right direction.
But my question remains, is there another way besides Tcpdump and/or
Wireshark to analyze these things. Turning on some debugging logs?
Kind regards,
Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
