On Mon, Feb 2, 2015 at 8:46 PM, walt <w41...@gmail.com> wrote: > On 02/02/2015 10:29 AM, Tom H wrote: >> On Sun, Feb 1, 2015 at 7:31 PM, walt <w41...@gmail.com> wrote: >>> >>> For example, I had to add the rpcbind.service to the multi-user >>> systemd target because even nfs3 seems to need it. >> >> You must mean "because especially nfsv3 needs it" because, >> theoretically, nfsv4 doesn't need rpcbind since an nfsv4 mount only >> needs to now about rpc.nfsd's default port 2049. > > This morning I got "waiting on lockfile foo in /usr/portage/distfiles" > "locking not available" from my nfs3 clients when trying to download > needed source files. > > I worked around this failure by using the nfs nolock mount option, and > then I gave up and restored nfs4 to all my kernels and nfs-utils packages. > > I don't recall having this problem back in my former nfs3-only days. > Maybe I've forgotten something obvious that I did back then?
There used to be an rpc.lockd daemon but lockd's been moved to a kernel module for nfsv3 and to nfsd for nfsv4. RHEL 5 has it (nfs-utils 1.09) and RHEL 6 doesn't (nfs-utils 1.2) so it must've been dropped with v1.1 or v1.2. I don't know when it was dropped in Gentoo terms (probably 6-7 years ago). Does this ring a bell? Does file locking work for an nfsv3 mount after you re-enable nfsv4 in your kernel config? If yes, then you're missing some kernel config that's being enabled automatically when you enable nfsv4. I can't think of what it might be since AFAIK you can't enable NFS_FS or NFSD without enabling FILE_LOCKING. If no, then are you setting static ports for statd and lockd and allowing access to these ports with iptables?
