Re: Regression: Missing check in nfsd_permission() causes -ENOLCK No locks available

[Olga Kornievskaia <aglo@umich.edu>]

On Fri, Feb 27, 2026 at 5:00 AM Thorsten Leemhuis
<regressions@leemhuis.info> wrote:
>
> [CCing a few people and lists]
>
> On 2/24/26 03:09, Tj wrote:
> > Upstream commit 4cc9b9f2bf4dfe13fe573 "nfsd: refine and rename
> > NFSD_MAY_LOCK" and
> >   stable v6.12.54 commit 18744bc56b0ec
>
> In case anyone just like me is wondering: the latter is a backport of
> the former.
>
> >  (re)moves checks from  fs/nfsd/vfs.c::nfsd_permission().>   This causes NFS clients to see
> >
> > $ flock -e -w 4 /srv/NAS/test/debian-13.3.0-amd64-netinst.iso sleep 1
> > flock: /srv/NAS/test/debian-13.3.0-amd64-netinst.iso: No locks available
>
> Does this happen on mainline (e.g. 7.0-rc1) as well?

I believe it probably does.

I could be wrong but I suspect that this occurs when the user running
flock does not have write access to the file it's trying to get an
exclusive lock on. Furthermore, it has been noted that the export
policy of the server contains "auth_nlm".

I ran into this before and there is an email thread titled: "[PATCH
3/3] nfsd: reset access mask for NLM calls in nfsd_permission" which
tried to "fix the nfsd: refine and rename NFSD_MAY_LOCK" (this is in
the middle of the discussion link
https://www.spinics.net/lists/linux-nfs/msg111534.html .. that
basically says flock should fail) . There was a period of time related
to commit 4cc9b9f2bf4d when such access was allowed until it was not.

Change export policy to no_auth_nlm if it's desired that flock gets an
exclusive lock on a file without write permissions. Or give write
permissions to get


>
> Ciao, Thorsten
>
> > Keeping the check in nfsd_permission() whilst also copying it to
> > fs/nfsd/nfsfh.c::__fh_verify() resolves the issue.
> >
> > This was discovered on the Debian openQA infrastructure server when
> > upgrading kernel from v6.12.48 to later v6.12.y where worker hosts (with
> > any earlier or later kernel version) pass NFSv3 mounted ISO images to
> > qemu-system-x86_64 and it reports:
> >
> > !!! : qemu-system-x86_64: -device
> > scsi-cd,id=cd0-device,drive=cd0-overlay0,serial=cd0: Failed to get
> > "consistent read" lock: No locks available
> > QEMU: Is another process using the image
> > [/var/lib/openqa/pool/2/20260223-1-debian-testing-amd64-netinst.iso]?
> >
> > A simple reproducer with the server using:
> >
> > # cat /etc/exports.d/test.exports
> > /srv/NAS/test
> > fdff::/64(fsid=0,rw,no_root_squash,sync,no_subtree_check,auth_nlm)
> >
> > and clients using:
> >
> > # mount -t nfs [fdff::2]:/srv/NAS/test /srv/NAS/test -o
> > proto=tcp6,ro,fsc,soft
> >
> > will trigger the error as shown above:
> >
> > $ flock -e -w 4 /srv/NAS/test/debian-13.3.0-amd64-netinst.iso sleep 1
> > flock: /srv/NAS/test/debian-13.3.0-amd64-netinst.iso: No locks available
> >
> > A simple test program calling fcntl() with the same arguments QEMU uses
> > also fails in the same way.
> >
> > $ ./nfs3_range_lock_test
> > /srv/NAS/test/debian-13.3.0-amd64-netinst.{iso,overlay}
> > Opened base file: /srv/NAS/test/debian-13.3.0-amd64-netinst.iso
> > Opened overlay file: /srv/NAS/test/debian-13.3.0-amd64-netinst.overlay
> > Attempting lock at 4 on /srv/NAS/test/debian-13.3.0-amd64-netinst.iso
> > fcntl(fd, F_GETLK, &fl) failed on base: No locks available
> > Attempting lock at 8 on /srv/NAS/test/debian-13.3.0-amd64-netinst.overlay
> > fcntl(fd, F_GETLK, &fl) failed on overlay: No locks available
> >
> >
>
>