Ubuntu
nfs-utils package

very long delay, or "RPC: Timed out" when mounting exports in a client which is not in server's /etc/hosts

Bug #28166 reported by Pekka Jääskeläinen
8
Affects Status Importance Assigned to Milestone
Ubuntu
Fix Released
Medium
Unassigned
nfs-utils (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

It took a while for me to figure out what's wrong with this.

My configuration is the following:

192.168.0.2 is the server with Kubuntu 5.10, nfs-kernel-server installed,
sharing a couple of directories to my other computers.

The clients that access the nfs exports are assigned the ips 192.168.0.3 and .4.

When I hadn't given names for the client machines in the server's /etc/hosts,
trying to mount the exports in the clients usually resulted in "RPC: Timed out"
error, or took *very* long to mount. The weird thing is that the mounting
*sometimes*, but very rarely worked, only the delay was very long.

So, a workaround for this is to add entries to the server's /etc/hosts for each IPs
you want to mount the nfs exports to. I added entries like this to /etc/hosts:

192.168.0.3 armada
192.168.0.4 nestori

After which the NFS exports seem to mount reliably. I think it's a bug somewhere,
but not sure in which package really.

Revision history for this message
Matt Zimmerman (mdz) wrote :

Working fine here without any such entries in /etc/hosts; perhaps a problem with your DNS server?

Revision history for this message
David Arcos Sebastián (dzpm) wrote :

Noticed the same bug here.

Same config: Ubuntu 5.10, in server mode (no gnome nor kde, just console), with nfs-kernel-server and nfs-user-server packages. And sharing a directory with the local network (192.168.1.*).

In /etc/exports I only allow this local network to access the share. But when mounting from a machine from the local network (i.e, 192.168.1.2) the mount stands for a very long delay (more than one minute, sometimes two). Sometimes it doesn't even mount, "RPC: Timed out".

The temporal workaround: I just changed /etc/exports to allow single IP's (and not full ranges of ip's) to access the share. This way it works and get mounted in less than a second.
This is obviously a dirty hack and not a definitive solution, so I would like to confirm the bug and hope that it will not appear in Dapper.

I can confirm that there is no relation with the DNS server, I tried it with the two machines isolated from the network, just by direct connection. And the temporal solution didn't involved the use of DNS server nor /etc/hosts.

Don't know in which package is the bug.

The bug doesn't seem critical, just a bit annoying.

Revision history for this message
David Arcos Sebastián (dzpm) wrote :

Sorry, wrong report. It was not NFS fault; the cause was that the client had not installed "portmap".

The "client" happened to be a live-cd of ubuntu 5.10. It had no "portmap" installed. Just "apt-get install portmap", and it works flawlessly.

Maybe in future versions of the live-cd "portmap" can be installed by default.

Revision history for this message
Alex Muntada (alex.muntada) wrote :

Can you please confirm that you still experience this problem with latest Dapper (or Edgy)?
In that case, please attach your exports file.

I've seen issues liket this caused by DNS problems in different Unix flavours and GNU/Linux
distributions, so I'd guess that Matt was right.

Changed in nfs-utils:
status: Unconfirmed → Needs Info
Revision history for this message
Pekka Jääskeläinen (pekka-jaaskelainen) wrote :

Haven't had any problems with this for a while, all my computers now run Dapper, so I suppose it's now fixed.

Thanks.

Revision history for this message
Alex Muntada (alex.muntada) wrote :

Fixed on Dapper.

Changed in nfs-utils:
status: Needs Info → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.