Re: [gentoo-user] Re: [NOTE] New default behavior in latest nfs-utils (1.3.2-r1)

[Tom H]

On Mon, Feb 2, 2015 at 8:46 PM, walt <w41ter@×××××.com> wrote:
> On 02/02/2015 10:29 AM, Tom H wrote:
>> On Sun, Feb 1, 2015 at 7:31 PM, walt <w41ter@×××××.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?