NFS not cooperating after portmap to rpcbind migration

Question

So yes, this is bugging me. I am starting to miss my series and if I don't get this fixed quick I'll have to go through a full detox .
So I call upon you for assistance!
As per this post on the frontpage, I replaced portmap with rpcbind and fixed my rc.conf (and services script that I run after mounting my data partition - it requires user intervention - too), but no dice.
Here's what I got:
/etc/exports
/var/data/series 10.0.0.20(ro,async,no_root_squash,subtree_check)
/var/data/films 10.0.0.20(ro,async,no_root_squash,subtree_check)
/etc/hosts.allow
# /etc/hosts.allow
# SSH access (open to the world since it's fortified anyway, right?)
sshd: ALL
vsftpd: ALL
#lighttpd: 192.168.1.
#mysqld : 192.168.1.
nfsd: 10.0.0.20
#lockd: 192.168.1.2
#rquotad: 192.168.1.2
rpcbind: 10.0.0.20
rpc.mountd: 10.0.0.20
rpc.statd: 10.0.0.20
# End of file
I really should throw out nfsd, since there's no such thing anymore. I've checked netstat for stuff listening worlwide (sounds fancy eh) but other than those three rpc* services I could not find anything related (I disabled the imadp stuff or whatever that is since the comments said only NFS v4 stuff needed it).
/etc/conf.d/nfs-common
# Parameters to be passed to nfs-common (nfs clients & server) init script.
# If you do not set values for the NEED_ options, they will be attempted
# autodetected; this should be sufficient for most people. Valid alternatives
# for the NEED_ options are "yes" and "no".
# Do you want to start the statd daemon? It is not needed for NFSv4.
NEED_STATD=
# Options to pass to rpc.statd.
# See rpc.statd(8) for more details.
# N.B. statd normally runs on both client and server, and run-time
# options should be specified accordingly. Specifically, the Arch
# NFS init scripts require the --no-notify flag on the server,
# but not on the client e.g.
# STATD_OPTS="--no-notify -p 32765 -o 32766" -> server
# STATD_OPTS="-p 32765 -o 32766" -> client
STATD_OPTS="--no-notify -p 32765 -o 32766"
# Options to pass to sm-notify
# e.g. SMNOTIFY_OPTS="-p 32764"
SMNOTIFY_OPTS="-p 32764"
# Do you want to start the idmapd daemon? It is only needed for NFSv4.
NEED_IDMAPD=no
# Options to pass to rpc.idmapd.
# See rpc.idmapd(8) for more details.
IDMAPD_OPTS=
# Do you want to start the gssd daemon? It is required for Kerberos mounts.
NEED_GSSD=
# Options to pass to rpc.gssd.
# See rpc.gssd(8) for more details.
GSSD_OPTS=
# Where to mount rpc_pipefs filesystem; the default is "/var/lib/nfs/rpc_pipefs".
PIPEFS_MOUNTPOINT=
# Options used to mount rpc_pipefs filesystem; the default is "defaults".
PIPEFS_MOUNTOPTS=
/etc/conf.d/nfs-server
# Parameters to be passed to nfs-server init script.
# Options to pass to rpc.nfsd.
# See rpc.nfsd(8) for more details.
NFSD_OPTS=
# Number of servers to start up; the default is 8 servers.
NFSD_COUNT="2"
# Where to mount nfsd filesystem; the default is "/proc/fs/nfsd".
PROCNFSD_MOUNTPOINT=
# Options used to mount nfsd filesystem; the default is "rw,nodev,noexec,nosuid".
PROCNFSD_MOUNTOPTS=
# Options for rpc.mountd.
# If you have a port-based firewall, you might want to set up
# a fixed port here using the --port option.
# See rpc.mountd(8) for more details.
MOUNTD_OPTS="--no-nfs-version 1 --no-nfs-version 2"
# Do you want to start the svcgssd daemon? It is only required for Kerberos
# exports. Valid alternatives are "yes" and "no"; the default is "no".
NEED_SVCGSSD=
# Options to pass to rpc.svcgssd.
# See rpc.svcgssd(8) for more details.
SVCGSSD_OPTS=
I am launching rpcbind, nfs-common and nfs-server (in that order), and if I may believe the service scripts, everything goes well. However my client, a HDX-1000, does not see any NFS shares at all (they are NFS v3 shares). Several reboots of both the server and client did not help (after fiddling with services and restarting them too, that is). If anybody has any clues: please .
As a totally unrelated sidenote: suddenly my HDX-1000 has decided it does like Mediatomb and happily plays back whatever it streams (ever since I bought the bloody damn thing it has been refusing to do so - which is why I set up NFS in the first place). So I don't need to fix this, but just for the sake of it (and because I know how quirky this HDX-1000 is) I'd like to fix it so I have a fallback option in case that shiny metal thing decides to act up again.

Answer 1

jealma wrote:Add mountd to your hosts.allow. I had not yet adapted my hosts.allow until I saw your post, but now I added rpcbind, rpc.mountd and rpc.statd. I also uncommented nfs, portmap and mountd, after which I couldn't mount my NFS share. After uncommenting mountd, I could mount again.
There is no mountd anymore:
[root@amalthea stijn]# netstat -puntal
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:57472 0.0.0.0:* LISTEN 3642/rpc.mountd
tcp 0 0 0.0.0.0:2049 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:55555 0.0.0.0:* LISTEN 3577/mediatomb
tcp 0 0 0.0.0.0:35081 0.0.0.0:* LISTEN -
tcp 0 0 10.0.0.15:6666 0.0.0.0:* LISTEN 3562/mpd
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 3592/rpcbind
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 3224/sshd
tcp 0 0 0.0.0.0:32765 0.0.0.0:* LISTEN 3612/rpc.statd
tcp 0 960 10.0.0.15:22 10.0.0.5:37903 ESTABLISHED 3547/sshd: stijn [p
udp 0 0 0.0.0.0:2049 0.0.0.0:* -
udp 0 0 10.0.0.15:44302 78.47.136.197:123 ESTABLISHED 3222/ntpd
udp 0 0 0.0.0.0:795 0.0.0.0:* 3592/rpcbind
udp 0 0 0.0.0.0:54820 0.0.0.0:* 3642/rpc.mountd
udp 0 0 10.0.0.15:39719 212.68.197.145:123 ESTABLISHED 3222/ntpd
udp 0 0 0.0.0.0:820 0.0.0.0:* 3612/rpc.statd
udp 0 0 10.0.0.15:57921 85.158.108.151:123 ESTABLISHED 3222/ntpd
udp 0 0 127.0.0.1:33730 0.0.0.0:* 3577/mediatomb
udp 0 0 10.0.0.15:43468 81.246.92.140:123 ESTABLISHED 3222/ntpd
udp 0 0 0.0.0.0:1900 0.0.0.0:* 3577/mediatomb
udp 0 0 10.0.0.15:53102 212.3.228.111:123 ESTABLISHED 3222/ntpd
udp 0 0 0.0.0.0:111 0.0.0.0:* 3592/rpcbind
udp 0 0 10.0.0.15:39546 193.41.86.177:123 ESTABLISHED 3222/ntpd
udp 0 0 0.0.0.0:60539 0.0.0.0:* -
udp 0 0 0.0.0.0:32765 0.0.0.0:* 3612/rpc.statd
udp 0 0 10.0.0.15:57855 79.99.122.30:123 ESTABLISHED 3222/ntpd
Checking for rpc and mountd gives these results:
[root@amalthea stijn]# whereis rpc
rpc: /usr/sbin/rpc.idmapd /usr/sbin/rpc.statd /usr/sbin/rpc.mountd /usr/sbin/rpc.svcgssd /usr/sbin/rpc.gssd /usr/sbin/rpc.nfsd /etc/rpc /usr/include/rpc /usr/share/man/man3/rpc.3t.gz /usr/share/man/man3/rpc.3.gz /usr/share/man/man5/rpc.5.gz /usr/share/man/man3x/rpc.3t.gz /usr/share/man/man3x/rpc.3.gz
[root@amalthea stijn]# whereis mountd
mountd: /usr/share/man/man8/mountd.8.gz
Tomk: I doublechecked again - the hosts.{allow,deny} files are very verbose about their syntax . So I wasn't sure too, but some googling told me I should be using the right format:
daemon_list : client_list [ : shell_command ]
If you ask me it would be rather silly for the hosts files to allow/deny connections on such a rough basis. I understood tcp_wrappers is a basic (yet in some way configurable) traffic blocker, a bit more low-level than iptables is for example. Also, if you can only say 'allow all incoming connections from any client' or 'block all connections from all clients', why are there two files then? Wouldn't it be easier just to use one file and set it to yes/no? I might be wrong ofcourse .
Anyway, I noticed whereis breaks on the dot, maybe it is expanded in the hosts files too (I hope not... Would be pesky). I will try with an ALL: ALL though to see if that fixes anything.