Ubuntu – NFS mount with file locking not possible any more after move to new subnet: statd timed out, lockd cannot monitor

nfssubnetUbuntu

I'm operating an Ubuntu 10.04 NFS Server with LDAP user authentication on a virtual machine in Subnet A. The server exports the users home directories with nfs v3 to ubuntu clients in subnets B and C. The server has other services runing, that shouldn't matter for my problem at the moment. Everything worked fine for several years.

Now we moved to a new building and got a new subnet D (hosts in subnet B and C became the new subnet D). Furthermore, the connection to the computing center, where my virtual servers are hosted, has now one kilometer of a cable from a commercial provider in between and has a smaller bandwidth. These are the only two things that have changed to my knowledge.

The problem is now, that I can only make working connections/mounts from the clients by using the nolock option. If this option is not provided, I get the following message on the server in /var/log/syslog

kernel: [11457.902470] statd: server rpc.statd not responding, timed out
kernel: [11457.902481] lockd: cannot monitor notos

and on clients with home mounted without the nolock option the users can not open any programs with a gui that tries to set file locks (google-chrome,…) or can even not log in (since locking is required as well).

On the first days after the move, when we only had half of the clients in the new subnet, I was not aware of the problem or it hasn't even been there.

Beside many other things, I tried what is described in this launchpad bug description. I thought the commercial provider might not be multicast able. But it didn't have any effect.

Any help would be appriciated.

Best Answer

If you want to use locks with NFS (and one really should!), your server must provide a RPC server where the clients can connect to. This is for coordinating locks.

Verify that the RPC server is running. If so, there must be something else blocking the communication between your clients and the RPC server. Since you seem to have general network connectivity, there must be a firewall (either on the server or the client itself, or somewhere between your clients and the server) blocking the connection attempts.

Related Topic