Attempting to NFSv4 mount a file system from an NFS server running the
rpc.mountd from nfs-utils-1.2.6 will hang indefinitely if the file
system in question is not exported to the client machine. Attempting
to mount the same, non-exported file system using NFSv3 will produce
the expected error message: "mount.nfs: access denied by server while
mounting ....".
This problem seems to stem from a change in the 1.2.6 version of
the nfs-utils mountd program: utils/mountd/cache.c[auth_unix_ip()].
In the 1.2.5 version of auth_unix_ip the code is:
/* addr is a valid, interesting address, find the domain name... */
if (!use_ipaddr) {
ai = client_resolve(tmp->ai_addr);
client = client_compose(ai);
freeaddrinfo(ai);
}
freeaddrinfo(tmp);
qword_print(f, "nfsd");
qword_print(f, ipaddr);
....
I.e., mountd *always* wrote at least the ip address down the
/proc/net/rpc/auth.unix.ip/channel pipe in response to kernel upcall.
In the 1.2.6 version of auth_unix_ip the code is:
/* addr is a valid, interesting address, find the domain name... */
if (!use_ipaddr) {
struct addrinfo *ai = NULL;
ai = client_resolve(tmp->ai_addr);
if (ai == NULL)
goto out;
client = client_compose(ai);
freeaddrinfo(ai);
if (!client)
goto out;
}
qword_print(f, "nfsd");
qword_print(f, ipaddr);
...
out:
In this latter case, the kernel upcall is responded to only if the
requesting IP address is associated with an exported file system.
Without the response the kernel waits about 5 seconds and then
drops the NFS request (PUTROOTFH,GETATTR,...) and leaves the client
hanging.
--
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
