Now that I've tried out NFS v4 on Ubuntu 22.04, I have some additional notes on NFS v4 locks and /proc/locks, to go with my earlier notes on NFS (v3) locks. It turns out that there are some changes from NFS v3 to NFS v4, at least on your NFS server.

Here is what an exclusive POSIX lock looks like on an Ubuntu 22.04 NFS v4 server:

4: POSIX  ADVISORY  WRITE 704 fc:02:669294 0 EOF
5: DELEG  ACTIVE    READ 704 fc:02:669294 0 EOF

The equivalent information from lslocks is:

nfsd    704 DELEG   READ  0     0   0 /...
nfsd    704 POSIX   WRITE 0     0   0 /...

There are two obvious differences in this. First, the process ID owning the lock is for one of your nfsd processes, not lockd. This is likely because in NFS v4, locking is integrated into the NFS protocol instead of being an additional set of protocols with separate daemons. The second is that there is this strange 'DELEG ACTIVE' (pseudo-)lock. I believe that this is a NFS v4 read delegation, where the server promises the client that it will be notified before anyone else is allowed to write to the file. Read delegations (usually) appear when a file is opened on the NFS client, not just when you take a lock, but since Unix locking works on file descriptors, you necessarily have to have an open file before you can get a lock. These delegations may linger after the relevant process on the NFS client has closed the file in question.

(Looking at the source code, it appears that a 'LEASE' type is also possible in general, although I don't know if it appears in NFS v4. The 'ACTIVE' status can also be 'BREAKING' or 'BREAKER'. All of this is in the kernel's lock_get_status() in fs/locks.c.)

The process ID may be less predictable than it is for NFS v3 locks, since there are generally multiple nfsd processes and I'm not sure if there is any consistency about which one becomes the owner of any particular lock. You may need to check against every nfsd process ID if you want to identify NFS v4 server locks.

Although I'm not completely sure what's going on in NFS v4, getting a shared lock on a file opened for reading with with either fcntl() or flock() produces no visible POSIX lock on the NFS v4 server, just a DELEG READ entry. If you open the file for writing and then take s shared lock, you do get a POSIX lock visible on the NFS server. The shared lock still works (ie, it prevents an exclusive lock from being acquired), so something is going on.

Unlike the situation with NFS v3 locks, where you have to dig into the kernel data structures to find the client who owns a lock, it appears that the NFS v4 server directly exposes this information in files under /proc/fs/nfsd. Based on casual inspection, 'clients/<id>/states' appears to contain information on delegations and locks from that client, while 'clients/<id>/info' identifies the client. Actual locks in the 'states' file are 'type: lock', as opposed to the other types (which may appear in quantity, due to delegations).

(A number of states show up in the 'states' file and I don't know enough about NFS v4 right now to understand them, or how the states change as you do various things.)