nfs - impossible to mount a remote nfs-share
I have a Ubuntu-Server with a configured NFS-Share. It's possible to mount this share on an other host which run's kubuntu. If I try to mount the share with my grml hd installation with
# mount -t nfs server:/share /mnt/server
I get the following error:
mount.nfs: rpc.statd is not running but is required for remote locking Either use "-o nolocks" to keep locks local, or start statd.
If I try to start rpc.statd with
# /etc/init.d/nfs-common
it takes about 1 minute to finish "Starting NFS common utilities: statd.", but id doesn't change anything.
# ps ax | grep statd gives no output
# rpcinfo -p localhost rpcinfo: can't contact portmapper: RPC: Remote system error - Connection timed out
# ps ax | grep portmap 4410 ? Ss 0:00 /sbin/portmap -i 127.0.0.1
Installed versions: - portmap 6.0-2 - nfs-common 1:1.1.0-6
Any Ideas why I cannot start nfs-common?
Regards, Frank
* Frank Eisenblaetter feisenbl@gmx.de [20070711 21:15]:
I have a Ubuntu-Server with a configured NFS-Share. It's possible to mount this share on an other host which run's kubuntu. If I try to mount the share with my grml hd installation with
# mount -t nfs server:/share /mnt/server
I get the following error:
mount.nfs: rpc.statd is not running but is required for remote locking Either use "-o nolocks" to keep locks local, or start statd.
If I try to start rpc.statd with
# /etc/init.d/nfs-common
it takes about 1 minute to finish "Starting NFS common utilities: statd.", but id doesn't change anything.
# ps ax | grep statd gives no output
# rpcinfo -p localhost rpcinfo: can't contact portmapper: RPC: Remote system error - Connection timed out
# ps ax | grep portmap 4410 ? Ss 0:00 /sbin/portmap -i 127.0.0.1
Installed versions:
- portmap 6.0-2
- nfs-common 1:1.1.0-6
Any Ideas why I cannot start nfs-common?
Please try running:
wget http://snapshot.debian.net/archive/2007/06/03/debian/pool/main/p/portmap/por... dpkg -i portmap_6.0-0_i386.deb Restart portmap Restart nfs-common
The current portmap package (6.0-2) in Debian/unstable seems to have a serious problem (I can reproduce it here as well), I'm trying to debug and report it to Debian's BTS. Please use portmap_6.0-0 in the meanwhile - I put it into grml-stable repository as well so grml users upgrading their systems won't run into this problem until it's resolved.
regards, -mika-
* Michael Prokop mika@grml.org [070711 21:42]:
- Frank Eisenblaetter feisenbl@gmx.de [20070711 21:15]:
I have a Ubuntu-Server with a configured NFS-Share. It's possible to mount this share on an other host which run's kubuntu. If I try to mount the share with my grml hd installation with
# mount -t nfs server:/share /mnt/server
I get the following error:
mount.nfs: rpc.statd is not running but is required for remote locking Either use "-o nolocks" to keep locks local, or start statd.
If I try to start rpc.statd with
# /etc/init.d/nfs-common
it takes about 1 minute to finish "Starting NFS common utilities: statd.", but id doesn't change anything.
# ps ax | grep statd gives no output
# rpcinfo -p localhost rpcinfo: can't contact portmapper: RPC: Remote system error - Connection timed out
# ps ax | grep portmap 4410 ? Ss 0:00 /sbin/portmap -i 127.0.0.1
Installed versions:
- portmap 6.0-2
- nfs-common 1:1.1.0-6
Any Ideas why I cannot start nfs-common?
Please try running:
wget http://snapshot.debian.net/archive/2007/06/03/debian/pool/main/p/portmap/por... dpkg -i portmap_6.0-0_i386.deb Restart portmap Restart nfs-common
The current portmap package (6.0-2) in Debian/unstable seems to have a serious problem (I can reproduce it here as well), I'm trying to debug and report it to Debian's BTS. Please use portmap_6.0-0 in the meanwhile - I put it into grml-stable repository as well so grml users upgrading their systems won't run into this problem until it's resolved.
Thanks for fast reply. I downgraded portmap to 6.0-0 as you descibed but that didn't change anything. I still get the same error message as described above. It takes about 3 min to finish a
Restart portmap
* Frank Eisenblaetter feisenbl@gmx.de [20070711 23:04]:
- Michael Prokop mika@grml.org [070711 21:42]:
- Frank Eisenblaetter feisenbl@gmx.de [20070711 21:15]:
[...]
mount.nfs: rpc.statd is not running but is required for remote locking Either use "-o nolocks" to keep locks local, or start statd.
If I try to start rpc.statd with
# /etc/init.d/nfs-common
it takes about 1 minute to finish "Starting NFS common utilities: statd.", but id doesn't change anything.
[...]
Please try running:
wget http://snapshot.debian.net/archive/2007/06/03/debian/pool/main/p/portmap/por... dpkg -i portmap_6.0-0_i386.deb Restart portmap Restart nfs-common
The current portmap package (6.0-2) in Debian/unstable seems to have a serious problem (I can reproduce it here as well), I'm trying to debug and report it to Debian's BTS. Please use portmap_6.0-0 in the meanwhile - I put it into grml-stable repository as well so grml users upgrading their systems won't run into this problem until it's resolved.
Thanks for fast reply. I downgraded portmap to 6.0-0 as you descibed but that didn't change anything. I still get the same error message as described above. It takes about 3 min to finish a
Restart portmap
Very interesting. On my system it works after booting and when running:
# Restart nfs-common
then.
I just stumbled upon:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=432511
Are you using kernel 2.6.22? I'm using 2.6.22-grml here with all packages being up2date (what will be available soon as new develrelease 1.0-1). Looks like a portmap/nfs-common<->2.6.22 issue.
regards, -mika-
* Michael Prokop mika@grml.org [070712 17:52]:
- Frank Eisenblaetter feisenbl@gmx.de [20070711 23:04]:
- Michael Prokop mika@grml.org [070711 21:42]:
- Frank Eisenblaetter feisenbl@gmx.de [20070711 21:15]:
[...]
mount.nfs: rpc.statd is not running but is required for remote locking Either use "-o nolocks" to keep locks local, or start statd.
If I try to start rpc.statd with
# /etc/init.d/nfs-common
it takes about 1 minute to finish "Starting NFS common utilities: statd.", but id doesn't change anything.
[...]
Please try running: wget http://snapshot.debian.net/archive/2007/06/03/debian/pool/main/p/portmap/por... dpkg -i portmap_6.0-0_i386.deb Restart portmap Restart nfs-common
[...]
Thanks for fast reply. I downgraded portmap to 6.0-0 as you descibed but that didn't change anything. I still get the same error message as described above. It takes about 3 min to finish a
Restart portmap
Very interesting. On my system it works after booting and when running:
# Restart nfs-common
then.
I just stumbled upon:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=432511
Are you using kernel 2.6.22? I'm using 2.6.22-grml here with all packages being up2date (what will be available soon as new develrelease 1.0-1). Looks like a portmap/nfs-common<->2.6.22 issue.
portmap 6.0-0
# uname -r 2.6.20-grml
nfs-common 1:1.1.0-6
After reboot portmap gets started automatically.
# ps ax | grep portmap 4409 ? Ss 0:00 /sbin/portmap -i 127.0.0.1
If I try to start nfs-common:
# Restart nfs-common Stopping NFS common utilities: idmapd statd. Starting NFS common utilities: statd
At this point there is a delay of about 3 min till I get a new prompt.
If I do a:
# ps ax | grep statd
I see no rpc.statd or somthing like that.
I don't think it's the same problem as in bug #432511 because I cannot restart nfs-common.
Regards, Frank
* Frank Eisenblaetter feisenbl@gmx.de [20070712 19:14]:
- Michael Prokop mika@grml.org [070712 17:52]:
Very interesting. On my system it works after booting and when running:
# Restart nfs-common
then.
portmap 6.0-0
# uname -r 2.6.20-grml
nfs-common 1:1.1.0-6
After reboot portmap gets started automatically.
# ps ax | grep portmap 4409 ? Ss 0:00 /sbin/portmap -i 127.0.0.1
[...]
Localhost only? Is that what you want?
Did you activate 'OPTIONS="-i 127.0.0.1"' inside your /etc/default/portmap? Try disabling that option, does it work then?
regards, -mika-
* Michael Prokop mika@grml.org [070712 19:29]:
- Frank Eisenblaetter feisenbl@gmx.de [20070712 19:14]:
- Michael Prokop mika@grml.org [070712 17:52]:
Very interesting. On my system it works after booting and when running:
# Restart nfs-common
then.
portmap 6.0-0
# uname -r 2.6.20-grml
nfs-common 1:1.1.0-6
After reboot portmap gets started automatically.
# ps ax | grep portmap 4409 ? Ss 0:00 /sbin/portmap -i 127.0.0.1
[...]
Localhost only? Is that what you want?
Did you activate 'OPTIONS="-i 127.0.0.1"' inside your /etc/default/portmap? Try disabling that option, does it work then?
I thought that I don't need portmap listening on an external interface on the client side. I don't think that this is the problem. I disabled this option and again the restart of portmap took extremly long and after that the problem still exists.
regards, feis
* Frank Eisenblaetter feisenbl@gmx.de [20070712 20:15]:
- Michael Prokop mika@grml.org [070712 19:29]:
Localhost only? Is that what you want? Did you activate 'OPTIONS="-i 127.0.0.1"' inside your /etc/default/portmap? Try disabling that option, does it work then?
I thought that I don't need portmap listening on an external interface on the client side. I don't think that this is the problem. I disabled this option and again the restart of portmap took extremly long and after that the problem still exists.
Does updating to nfs-common 1:1.1.0-8 help?
regards, -mika-
* Michael Prokop mika@grml.org [070713 16:04]:
- Frank Eisenblaetter feisenbl@gmx.de [20070712 20:15]:
- Michael Prokop mika@grml.org [070712 19:29]:
Localhost only? Is that what you want? Did you activate 'OPTIONS="-i 127.0.0.1"' inside your /etc/default/portmap? Try disabling that option, does it work then?
I thought that I don't need portmap listening on an external interface on the client side. I don't think that this is the problem. I disabled this option and again the restart of portmap took extremly long and after that the problem still exists.
Does updating to nfs-common 1:1.1.0-8 help?
Now I know portmap an nfs-common weren't the problem. The problem was that the loopbackinterface didn't come up automatically at boot. I set it to
auto lo
and now everything works perfect. So the problem was that statd couldn't contact portmap because of the missing loopback device.
I wonder why loopbackdevice isnt't configured to come up automatically at boot after a fresh hd installation.
regards, feis
* Frank Eisenblaetter feisenbl@gmx.de [20070715 18:15]:
- Michael Prokop mika@grml.org [070713 16:04]:
Does updating to nfs-common 1:1.1.0-8 help?
Now I know portmap an nfs-common weren't the problem. The problem was that the loopbackinterface didn't come up automatically at boot. I set it to
auto lo
and now everything works perfect. So the problem was that statd couldn't contact portmap because of the missing loopback device.
Ah, thanks for feedback.
I wonder why loopbackdevice isnt't configured to come up automatically at boot after a fresh hd installation.
By default that's activated at grml (/etc/network/interfaces):
# The loopback interface auto lo iface lo inet loopback
So if you use a grml system either you found a bug we weren't aware of yet (please report it if you find this behaviour once again) or you modified /etc/network/interfaces on your own. :)
Anyway, great that your issues seems to be fixed now.
regards, -mika-
On Wed, Jul 11, 2007 at 08:34:54PM +0200, Frank Eisenblaetter wrote:
# rpcinfo -p localhost rpcinfo: can't contact portmapper: RPC: Remote system error - Connection timed out
# ps ax | grep portmap 4410 ? Ss 0:00 /sbin/portmap -i 127.0.0.1
BTW: Is your network configured? I mean, is there any network device with an IP address (except loopback).
greets Jimmy
* Andreas Gredler jimmy@grml.org [070712 17:52]:
On Wed, Jul 11, 2007 at 08:34:54PM +0200, Frank Eisenblaetter wrote:
# rpcinfo -p localhost rpcinfo: can't contact portmapper: RPC: Remote system error - Connection timed out
# ps ax | grep portmap 4410 ? Ss 0:00 /sbin/portmap -i 127.0.0.1
BTW: Is your network configured? I mean, is there any network device with an IP address (except loopback).
My network is configured and I can ping and ssh to my server. I also can do
# rpcinfo -p server
program vers proto port 100000 2 tcp 111 portmapper 100000 2 udp 111 portmapper 100003 2 udp 2049 nfs 100003 3 udp 2049 nfs 100003 4 udp 2049 nfs 100021 1 udp 1024 nlockmgr 100021 3 udp 1024 nlockmgr 100021 4 udp 1024 nlockmgr 100003 2 tcp 2049 nfs 100003 3 tcp 2049 nfs 100003 4 tcp 2049 nfs 100021 1 tcp 4822 nlockmgr 100021 3 tcp 4822 nlockmgr 100021 4 tcp 4822 nlockmgr 100005 1 udp 769 mountd 100005 1 tcp 772 mountd 100005 2 udp 769 mountd 100005 2 tcp 772 mountd 100005 3 udp 769 mountd 100005 3 tcp 772 mountd 100024 1 udp 1026 status 100024 1 tcp 2485 status
Regards Frank
participants (3)
-
Andreas Gredler -
Frank Eisenblaetter -
Michael Prokop