getcwd() fails with "No such file or directory" within NFSv4 mount point

This document (7015695) is provided subject to the disclaimer at the end of this document.

Environment

SUSE Linux Enterprise Server 11 SP3

Situation

There are different scenarios during which this issue might happen. Just one is described below as an example.
This issue does appear on a system running SLES 11 SP3 with 3.0.101-0.35:
Executing "pwd" in an NFSv4 mount point fails in function getcwd(); here is the demonstration:

These two types of mounts were used to reproduce the problem:

NFSv3: 10.0.0.254:/data/requests on /mnt type nfs (rw,addr=10.0.0.254)

NFSv4: 10.0.0.254:/data/requests on /mnt type nfs4 (rw,addr=10.0.0.254,clientaddr=10.0.0.243)

Results of commands executed within /mnt:

3.0.101-0.31 - NFSv3:

$ strace pwd 2>&1 | grep getcwd

getcwd("/mnt", 4096)                    = 5

3.0.101-0.31 - NFSv4:

$ strace pwd 2>&1 | grep getcwd

getcwd("/mnt", 4096)                    = 5

3.0.101-0.35 - NFSv3:

$ strace pwd 2>&1 | grep getcwd

getcwd("/mnt", 4096)                    = 5

3.0.101-0.35 - NFSv4:

$ strace pwd 2>&1 | grep getcwd

getcwd(0x60cfa0, 4096)                  = -1 ENOENT (No such file or directory)

The last line does show that the issue happens with kernel 3.0.101-0.35 combined with NFSv4.
Tested NFS servers: SLES 11 SP3, IBM nSeries filer, netapp etc ...

Resolution

This issue was addressed with maintenance kernel update:
kernel-default-3.0.101-0.40.1

Disclaimer

This Support Knowledgebase provides a valuable tool for SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented "AS IS" WITHOUT WARRANTY OF ANY KIND.