HOWTO bug and nfs on Debian
Hello Again, Debianauts,
I've just come up against one of the most terrifying of all software
bugs: the "otherwise confidence-inspiring HOWTO omission bug". I thought
I'd write in about it, although I am beginning to think I am blacklisted
from Debian-User because none of my messages are showing up ;-).
Fought like two blue devils tonight to get NFS working between my laptop
(client) and a system henceforth to be referred to as "cherubic". The
"cherubic" computer is running these:
Package Version Notes
------ ------- ---------------------------
nfs-common 1.0-2 a.k.a. "nfs-utils"
nfs-user-server 2.2beta47-12 * See below
* needed bec. my kernel apparently can't do k-mode NFS (home-built
* kernel).
With kernel 2.4.18, on Woody (3.0r1).
To help me along I first read the documentation found (Google) at:
http://nfs.sourceforge.net/nfs-howto/index.html
I was finally rescued (and a few remaining hours of sleep won back) by
the advice found at (Google):
http://georg.linux.ee/trouble/20020717-nfs.txt
which advises that if one follows the security measures advice given in
the HOWTO, i.e. uses hosts.{allow,deny} to control access to the nfs
server-parts (mountd, portmapd) one must add an entry contrary to the
HOWTO's info in hosts.allow:
rpc.mountd: xxx.xxx.xxx.xxx
In the HOWTO it says [paraphr.] "use the server *names*, not the names
of the actual binaries." Apparently since at least 2.2 (Potato) Debian
has had this discrepancy between documented advice and actual need.
The symptom of having this wrong (missing the entry in hosts.allow) on
the client was the message "mount: RPC: Timed out" and on the server in
/var/log/messages was "cherubic mountd[1638]: access from host
192.xxx.xxx.xxx rejected".
Hope this helps someone in the future -- I am sure it will strike again.
[I've BCC'd to other addresses off-list]
Best,
Soren Andersen
--
GnuPG public key fingerprint: BD26 A5D8 D781 C96B 9936 310F 0573 A3D9 4E24 4EA6
Reply to: