NFS clientaddr over VPN: decide by minor version, not habit
clientaddr advertises a callback address for NFSv4.0 only. Read the negotiated minor version, check the return path, and separate it from mount failures.
clientaddr is one of those mount options that gets copied into a command line long after the reason for it is gone. It tells an NFSv4.0 server where to call the client back. It does not choose the server, bind every request to a source address, or push traffic into a tunnel. On a laptop with several addresses, deciding whether it applies at all takes three questions.
Three conditions decide whether the option matters
The first is the negotiated minor version, because 4.1 and 4.2 handle callbacks differently. The second is whether the server can reach the address you would advertise, which a routed tunnel usually allows and a translated path usually does not. The third is whether the failure you are chasing is a callback failure at all.
| Condition | If yes | If no |
|---|---|---|
| Version is 4.0 | The option can matter | Skip it; inspect the session instead |
| Server can reach the address | Advertise it | Fix reachability first |
| Failure is a callback | Diagnose callback path | Look at mount and export |
Answering them out of order is how people end up adding a callback address to a 4.2 mount and concluding that the option is broken.
Read the minor version first
nfsstat -mFor an existing mount, this prints the mount information and flags, including the effective version as vers=4.0, vers=4.1, or vers=4.2. A note that says only "NFSv4" omits the one detail that decides whether this option is relevant. Read the number rather than the word.
If the version string came from a server default rather than your command line, ask which minor version was negotiated. A server can refuse a higher minor version and fall back, and that fallback is exactly the case where a callback suddenly matters. The mount line you wrote may not describe the mount you have.
For 4.0, advertise an address the server can reach
An NFSv4.0 server may need a separate connection back to the client, for example when it recalls a delegation. With multiple interfaces or an unusual routing table, the automatic discovery of a callback address can pick one that the server cannot use.
mount -t nfs -o vers=4.0,clientaddr=10.8.0.6 10.8.0.1:/export /mnt/shareThe address before the colon is the server and stays the destination. The callback address belongs to the client, and it has to be reachable from the server's side of the tunnel. A loopback address points the server back at itself. A private client address with no return route is just as unusable, even though it looks correct on the client.
Use this as an illustration, not as a reason to downgrade a working mount. Replace the addresses and the export path, and keep the authentication and other options the server requires. Dropping them to make one example fit is a different change with a different result, and on a server that enforces a security flavour it fails before any callback is attempted.
4.1 and 4.2 do not use the option
Linux NFSv4.1 and 4.2 carry callbacks over connections the client established, and 4.1 names that facility the backchannel. They do not depend on the server opening a new connection to an advertised address, so clientaddr does not repair a 4.1 or 4.2 callback path.
That does not mean 4.1 and 4.2 have no callback problems. It means the diagnosis is different: inspect the established session and its backchannel state rather than looking for an inbound callback port that was never meant to exist. A missing inbound rule is the expected state, not a fault to correct.
Separate a mount failure from a callback failure
Establish first whether the client reaches the NFS service and whether the server accepts the export and the authentication request. A timeout before that exchange says nothing about a callback address. Changing one while the mount is still failing moves the investigation no closer, and it hides the original error behind a new mount option.
Only when the evidence shows a failed 4.0 callback does the advertised address matter, along with the server's return path, the client-side listener, and any filtering between them. Changing the number in the mount option cannot create those paths; it can only point at one that already exists. Write down which of those four you verified, because the next report will arrive without any of them.
An early-boot NFS root is a separate environment with its own prerequisites: the initramfs needs the tools and the network before the mount can happen. A mount that works after login proves nothing about that sequence, and the failure at boot rarely mentions either the initramfs or the network.