rpc.mountd v4.2 client detached — if you see this on your Proxmox host, don’t panic. It’s usually not an error. It’s the NFS server telling you a client dropped its connection and reattached. Happens all the time with TrueNAS-to-Proxmox mounts.
What the message actually means
NFSv4.2 is stateful. The server keeps track of open files, locks, and delegations for each client. When a client reboots, or the network hiccups, the server logs:
rpc.mountd[2790]: v4.2 client detached: 0x... from 192.168.1.50Then a moment later, if the client reconnects:
rpc.mountd[2790]: v4.2 client attached: 0x... from 192.168.1.50That’s it. The client lost its state, the server cleaned up, and the client came back. If your VMs and containers are still working, this is just noise in the log.
When it’s a real problem
Watch for these symptoms alongside the detach message:
- I/O errors in the guest — apps freezing, filesystem going read-only
- Repeated detach/attach cycles every few seconds
- NFS mount hangs or stale file handles
- Proxmox storage showing “unknown” or going offline
If you see those, then the detach is a symptom, not the cause. Check your network first — flaky switch, bad cable, or a NIC that’s negotiating at half duplex. Then look at the NFS server’s load. TrueNAS under heavy ZFS scrub or replication can stall NFS responses long enough for clients to time out.
How to reduce the noise
On the Proxmox side, you can adjust the NFS mount options. In /etc/pve/storage.cfg, add timeo=600,retrans=2 to your NFS storage definition. That makes the client more patient before it gives up and reattaches.
On TrueNAS, make sure you’re not using UDP for NFS. Force TCP. UDP drops are a classic cause of spurious detach messages.
If you’re running Proxmox in an LXC container with an NFS mount, check out this post on a working arr stack setup — it covers the mount options that keep things stable.
My take
This message is annoying I know. But it’s not a bug. It’s the server doing its job. The only time I’d dig deeper is if the detach messages come with actual I/O problems. Otherwise, ignore it and move on.
If you’re seeing NFS storage status unknown on a second node, that’s a different issue — here’s the fix.
