Lack of portmap makes nfs mounts slow

 status Rejected

You don't need portmap to mount nfs shares.

Hmm - if I try to NFS mount our servers the mount hangs - if I install portmap and then start the mount it works.

So, if I don't need portmap why does it hang - either way I have a problem where I can't mount NFS shares with the livecd; my fix is to start portmap; perhaps the problem is something else?

On zo, 2006-07-02 at 12:47 +0000, Dave Gilbert wrote:
> Hmm - if I try to NFS mount our servers the mount hangs - if I install
> portmap and then start the mount it works.

mount -tnfs is dead-slow here too (several minutes of waiting),
depending on the paramters
--
Dennis K.

Time is an illusion, lunchtime doubly so.

with portmap in, the mount -t nfs is instant like it should be

Perhaps I hadn't waited for the timeout (if it was several minutes
definitely); so it sounds like its trying to talk to portmap but eventually timing out.

Either way, an nfs mount shouldn't take minutes, so please unreject this bug - but feel free to change it to something like 'NFS mount takes ages on livecd' if that makes you happier.

Sounds reasonable :)

This bug has also been reported in bug 48366.

Portmap is definitely needed for nfs mounts - unless one considers 1m30s waits ok. It has nothing to do with the liveCD as such. The wait occurs also in Thunderbird when accessing nfs-mounted mail directories. Unless there is a good reason for not installing portmap I suggest to include it as default, or at least make the nfs client depend on it.

(The nfs mount program might also try and detect a missing portmap and issue a warning - would have saved me some hours of hunting for the error).

Affects also Edgy Eft Release candidate 20061019.

Toby

Setting package from (undefined) to portmap, so it gets out of the bug list without package.
Also, can you confirm this bug still applies in edgy/feisty?
Thanks

Leaving at confirmed. Hopefully a developer will look at it.

I can confirm it still occurs on feisty.
I've looked at what goes on with wireshark on 'lo'; something somewhere is doing a
portmap

  [Program Version: 2]
  [V2 Procedure: SET (1)]
  Program: NLM (100021)
  Version: 1
  Proto: TCP (6)
  Port: 38824

Which gave me an idea - it is locking related; adding -onolock makes the mount succeed in a few seconds.

I don't think I could argue for starting portmap by default - that would be insecure; but I think mount's behaviour without a local portmap should be more reasonable.

Dave

Installing package nfs-common fixes it for me, I wonder if anyone else would confirm this?

I haven't tried this yet, but it looks to me like nfs-common has a dependency on portmap - so is that causing it to install and start portmap?
What happens if you install nfs-common but explicitly stop portmap?

Dave

My bad. Killed the portmap process and tried to mount another nfs share, still seems to mount fine. I don't really know much about portmap, I'm probably missing something here.

I also had the problem that nfs took ages.

Installing portmap works for me - after installing it now mounts instantly.

To test, if I do /etc/init.d/portmap stop then mounting takes ages again.

Portmap isn't needed.
The problem is solved by using the '-o nolock' mount option.

However, I do agree it would be smart to recommend portmap in ubuntu-standard.