On Saturday, May 16th, 2026 at 6:10 PM, Otto Cooper <[email protected]> wrote:
> A solution was suggested to use NFS v4, as it builds lease-based file locking > directly into the protocol itself, dropping the need for rpc.lockd. > > Since OpenBSD does not implement NFS v4, I am now using the following client > side option: soft,timeo=30,retrans=3. > > Will see how it works. > > > On Friday, May 15th, 2026 at 10:37 AM, Otto Cooper <[email protected]> > wrote: > > > > > /var/log/daemon > > ... > > > May 15 09:51:51 openbsd rpc.lockd: duplicate lock from <clientid>.26203 > > > May 15 09:51:51 openbsd rpc.lockd: no matching entry for <clientid> > > > > Hello, > > > > The above log entry occurs frequently when a NFS client is connected via > > Wi-Fi. > > The client has its MAC on record, and a static IP assigned by DHCP. > > > > I see the problem with MacOS clients. > > I do not have evidence of the problem with other OS, not because they are > > immune but because I have not tested them yet. > > > > I suspect that when the client disconnects, because of sudden loss of > > signal, the client does not unlock the resource. When it reconnects, client > > and server are misaligned: the server holds the lock and expects the client > > to use it, but the client issues a new lock request instead. Or perhaps > > something else occurs. > > > > As this problem is occurring frequently, it is causing pains. > > > > Is anybody else seeing this? How did you solve the problem? > > > > Thank you. > > > > -- > > Otto It did not solve the problem. This is what I am now experimenting with. Server side (obsd): /etc/rc.conf.local: lockd_flags="-g 60" Client side (macos): -vers=3,tcp,rsize=32768,wsize=32768,soft,intr,resvport,timeo=300,retrans=10,nfc TLDR: I have a network of Wi-Fi clients, where NFSv4 or SAMBA are the modern solution for non-wired networks. Since openbsd runs NFSv3 only, where wired network is a must, I am hanging on the wall with bare nails.
