NFS not cooperating after portmap to rpcbind migration

.:B:. · 2009-06-25 21:33:58

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.

jealma · 2009-06-26 09:17:04

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.

jealma · 2009-06-26 09:26:47

Although I can mount the NFS share, I still have trouble using it. I constantly get stale NFS handles on my client, and the dmesg of the NFS server keeps repeating the "reconnect_path: npd != pd" line. It is about 25 times in my dmesg in a matter of minutes. Anyone know how to solve this?

tomk · 2009-06-26 14:03:42

No direct solution to offer, but I've had no trouble here so far. However, I haven't upgraded the server yet - it's still running portmap and nfs-utils 1.1.6. The clients are on the 1.2.0 package and rpcbind, and have no trouble mounting as before.

I'll post here if the server upgrade goes screwy.

Might be worth mentioning that hosts.allow on the server allows all connections, but only from specific subnets - iow, there is no specific line for mountd, rpc*, or any other individual service, just lines like 'ALL: 192.168.1.0/255.255.255.0'.

.:B:. · 2009-06-26 17:05:15

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.

tomk · 2009-06-27 00:18:07

B wrote:

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 ]

We're both using the right syntax - I just chose to put ALL on the left-hand-side of my directives, so that I wouldn't have to allow individual services explicitly.

B wrote:

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.

Not sure what you're getting at here. What 'roughness' are you talking about?
tcp_wrappers does what it does, but only for those apps that are built against it.

B wrote:

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?

I can answer the first part - you can't only say 'allow all...' or 'block all...', you can be more selective if you want (I don't). As for the two files thing, the man pages explain what they do, but you'd have to ask the developer why he did it that way.

tomk · 2009-06-27 00:38:05

Just upgraded the server - everything's still working fine. If anyone needs more details of my setup, just ask.

.:B:. · 2009-06-27 23:50:33

Mediatomb here still works, so I think I'll pass for the moment .

As for the tcp_wrappers/hosts.{allow,deny} thing: I think it boils down to a misunderstanding from my side . I was interpreting your statements as 'either you allow everything (with tcp_wrappers support, that is) or you deny it, but yes, you can do it on a per-app basis (if the app can work through tcp_wrappers).

zenlord · 2009-06-29 07:45:38

tomk wrote:

Just upgraded the server - everything's still working fine. If anyone needs more details of my setup, just ask.

If you don't mind, I would like to see your config files. In the past I have tried to connect my Arch client to my Debian server. Since the server was installed by someone else and 'fortified' with Kerberos authentication, I could not get it to work and I worked around it with samba.

But NFS is my weapon of choice for this and next weekend I have some spare time, so I might try it out on my own (Arch-) server...

Zl.

.:B:. · 2009-06-29 08:26:37

Edit: Misreading is an art...

tomk · 2009-06-29 14:18:50

zenlord, as requested:

server: /etc/exports

# /etc/exports: the access control list for filesystems which may be exported
#               to NFS clients.  See exports(5).

/common                 192.168.10.0/255.255.255.0(rw,all_squash,async,anonuid=1000,anongid=100,no_subtree_check) 10.12.62.0/255.255.255.0(rw,all_squash,async,anonuid=1000,anongid=100,no_subtree_check)
/general                192.168.10.0/255.255.255.0(rw,all_squash,async,anonuid=1000,anongid=100,no_subtree_check) 10.12.62.0/255.255.255.0(rw,all_squash,async,anonuid=1000,anongid=100,no_subtree_check)
/var/cache/pacman/pkg   192.168.10.0/255.255.255.0(rw,no_root_squash,async,no_subtree_check) 10.12.62.0/255.255.255.0(rw,no_root_squash,async,no_subtree_check) 10.1.3.10(rw,no_root_squash,async,no_subtree_check)

server: /etc/hosts.allow

#
# /etc/hosts.allow
#

ALL: 192.168.10.0/255.255.255.0
ALL: 10.12.62.0/255.255.255.0
ALL: 10.1.3.0/255.255.255.0

clients: /etc/fstab

server:/common    /common        nfs      tcp,rsize=32768,wsize=32768,rw,user,hard,intr    0    0
server:/general    /general    nfs      tcp,rsize=32768,wsize=32768,rw,user,hard,intr    0    0
server:/var/cache/pacman/pkg    /var/cache/pacman/pkg    nfs    tcp,rsize=32768,wsize=32768,rw,user,hard,intr    0    0

Let me know if there's anything else you need.

Arch Linux

#1 2009-06-25 21:33:58

NFS not cooperating after portmap to rpcbind migration

#2 2009-06-26 09:17:04

Re: NFS not cooperating after portmap to rpcbind migration

#3 2009-06-26 09:26:47

Re: NFS not cooperating after portmap to rpcbind migration

#4 2009-06-26 14:03:42

Re: NFS not cooperating after portmap to rpcbind migration

#5 2009-06-26 17:05:15

Re: NFS not cooperating after portmap to rpcbind migration

#6 2009-06-27 00:18:07

Re: NFS not cooperating after portmap to rpcbind migration

#7 2009-06-27 00:38:05

Re: NFS not cooperating after portmap to rpcbind migration

#8 2009-06-27 23:50:33

Re: NFS not cooperating after portmap to rpcbind migration

#9 2009-06-29 07:45:38

Re: NFS not cooperating after portmap to rpcbind migration

#10 2009-06-29 08:26:37

Re: NFS not cooperating after portmap to rpcbind migration

#11 2009-06-29 14:18:50

Re: NFS not cooperating after portmap to rpcbind migration

Board footer