Hi,
Recently upgraded to 2.2.19, along with new nfs-utils(0.3.1).
But I have a program that requires a exclusive write lock
on a NFSed directory. When I was using 2.2.17 all was ok,
but now it returns ENOLCK. Does anybody else have the
same problem?
Thanks
-Andrew
>>>>> " " == apark <[email protected]> writes:
> Hi, Recently upgraded to 2.2.19, along with new
> nfs-utils(0.3.1). But I have a program that requires a
> exclusive write lock on a NFSed directory. When I was using
> 2.2.17 all was ok, but now it returns ENOLCK. Does anybody
> else have the same problem? Thanks
Hi,
You are probably failing to run the statd daemon or you may have set
up over-restrictive /etc/hosts.(allow|deny).
See the latest NFS-HOWTO for a full description on how to set up
locking.
Cheers,
Trond
On 25 Apr 2001 00:39:43 +0200, Trond Myklebust <[email protected]> wrote:
>>>>>> " " == apark <[email protected]> writes:
>
> > Hi, Recently upgraded to 2.2.19, along with new
> > nfs-utils(0.3.1). But I have a program that requires a
> > exclusive write lock on a NFSed directory. When I was using
> > 2.2.17 all was ok, but now it returns ENOLCK. Does anybody
> > else have the same problem? Thanks
>
> Hi,
>
> You are probably failing to run the statd daemon or you may have set
> up over-restrictive /etc/hosts.(allow|deny).
Or /var/lib/nfs/statd does not exist on your system, or it is not
writable by the uid rpc.statd runs under (rpcuser on Red Hat boxes
with all the upgrades).
I've had this problem myself, I don't think it's covered in the FAQ.
I haven't checked if the rpcuser thing is a redhat-ism, probably is,
their script is not doing anything special with rpc.statd so they
must have hacked it into the executable.
Ion
--
It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.