Re: NFS client hang on 13.2-RELEASE-p2 on file locking / wrong interface selected

From: Rick Macklem <rick.macklem_at_gmail.com>
Date: Fri, 25 Aug 2023 01:52:12 UTC
On Thu, Aug 24, 2023 at 10:25 AM J David <j.david.lists@gmail.com> wrote:
>
> On Thu, Aug 24, 2023 at 10:02 AM Rick Macklem <rick.macklem@gmail.com> wrote:
> > Otherwise consider switching the mounts to NFSv4.1/4.2.
>
> Unfortunately, NFSv4 is worse.
>
> Under NFSv4.2, attempts to lock files that previously did not exist on
> NFS servers work, but any attempt to lock an existing file, regardless
> of permissions, inexplicably fails with "Permission denied."
>
> E.g.:
>
> $ lockf -k x sleep 3 && echo OK
> OK
> $ lockf -k x sleep 3 && echo OK
> lockf: cannot open x: Permission denied
Here's a  snippet from "man lockf"
-w                 Causes lockd to open file for writing rather than
                      reading.  This is necessary on filesystems (including
                       NFSv4) where a file which has been opened read-only
                       cannot be exclusively locked.

I am pretty sure this is in 13.2, although I do not remember when it
was added to "lockf".

rick

> $ rm x
> $ lockf -k x sleep 3 && echo OK
> OK
> $ ktrace lockf -k x sleep 3 && echo OK
> lockf: cannot open x: Permission denied
> $ echo "what" >x
> $ cat x
> what
>
> From ktrace:
>
>  98614 lockf    CALL
> openat(AT_FDCWD,0x295c0979e8f1,0x224<O_RDONLY|O_NONBLOCK|O_EXLOCK|O_CREAT>,0666<S_IRUSR|S_IWUSR|S_IRGRP|S_IWGRP|S_IROTH|S_IWOTH>)
>  98614 lockf    NAMI  "x"
>  98614 lockf    RET   openat -1 errno 13 Permission denied
>
> Thanks!