>> >> >> Indeed. Actually, by mistake, I was using the new 1.1.2 nfs-utils >> binaries and making changes in the old 1.1.0 nfs-utils source. The >> removal of the member does not change anything. What is happening is >> that an upgrade to the new 1.1.2 nfs-utils binaries solves the >problem. >> I think you can reproduce the problem at your end simply by unmounting >> nfsd filesystem and using 1.1.0 nfs-utils binary. > >OK! Hm, do you know which patch actually fixed this? (Is it actually >just the same problem you reported before?) No, it can't be the same patch. After I reported the issue and Neil gave me the patch, I applied the patch to our own nfs-utils source and thereafter, our build process has been using the patched nfs-utils binaries ever since. However, interestingly, the patch that was committed to the git repo is handles the issue slightly differently (though I think it should not create any difference). The patch Neil gave me is as follows: diff --git a/support/export/client.c b/support/export/client.c index 1cb242f..e96f5e0 100644 --- a/support/export/client.c +++ b/support/export/client.c @@ -462,5 +462,5 @@ client_gettype(char *ident) sp++; if(!isdigit(*sp) || strtoul(sp, &sp, 10) > 255 || *sp != '.') return MCL_FQDN; sp++; if(!isdigit(*sp) || strtoul(sp, &sp, 10) > 255 || *sp != '\0') return MCL_FQDN; /* we lie here a bit. but technically N.N.N.N == N.N.N.N/32 :) */ - return MCL_SUBNETWORK; + return MCL_FQDN; } On a quick skim through the >git history I'm not seeing it. Hmm, I also did a quick skip through the commit logs. Didn't quite see anything that might be relevant. However, I retested with 1.1.2 and again it *did* solve the issue. Interesting! A > >--b. -- 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
