Possible bug in the arch NFS server package?

Question

i run the nfs server on my arch box, exporting to a debian box and an arch laptop. whenever the arch server reboots lately, the shares don't automatically remount properly on the clients. they're listed in mtab, but if i ls or try to access the directories, i get a permission denied error. i have to manually unmount the shares and then remount them again to be able to see/use them.
the reason i think this is an arch package problem is because i set up a share on the debian box to share with arch, and that worked perfectly. when i rebooted debian as the server, the shares were automatically remounted on the arch client, and when i rebooted arch, the shares were again mounted properly on reboot.
it's possible i'm doing something wrong with permissions, but it seems unlikely because 1) everything was working fine for a long time until recently, when i started noticing the behavior,  2) all the permissions on the shared directory are identical to the ones on the arch shared directory, all user name UIDs are the same, same groups and GIDs, etc., 3) the shares mount perfectly well manually from the command line, and 4) i set up the debian share/exports, etc. in about 2 minutes with no problem at all, while dealing with this problem on arch for 2 days now, after changing options and going over everything multiple times until my head is spinning. it just seems unlikely that a configuration is wrong, although i guess anything is possible. i can provide all that permissions/group info, fstab info, /etc/exports info, etc. if anyone wants to take a closer look at it.
so until this is sorted, i wondered if anyone else is having this problem, or if anyone had any ideas of something i might be overlooking. again, everything *seems* to be set up right, but maybe there's some arch specific thing i'm overlooking. thanks.

Answer 1

Ok out of pure fustration I just grabbed the gentoo init script. Installed start-stop-daemon, modified the script to run as #!/bin/bash, stuck it in /etc/rc.d, rebooted and everything works, I can reboot my computer and clients reconnect. Or restart daemon and they reconnect.
Heres the script I am using.
#!/bin/bash
# Copyright 1999-2005 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/net-fs/nfs-utils/files/nfs,v 1.14 2007/03/24 10:14:43 vapier Exp $
# This script starts/stops the following
# rpc.statd if necessary (also checked by init.d/nfsmount)
# rpc.rquotad if exists (from quota package)
# rpc.nfsd
# rpc.mountd
# NB: Config is in /etc/conf.d/nfs
opts="reload"
# This variable is used for controlling whether or not to run exportfs -ua;
# see stop() for more information
restarting=no
# The binary locations
exportfs=/usr/sbin/exportfs
gssd=/usr/sbin/rpc.gssd
idmapd=/usr/sbin/rpc.idmapd
mountd=/usr/sbin/rpc.mountd
nfsd=/usr/sbin/rpc.nfsd
rquotad=/usr/sbin/rpc.rquotad
statd=/usr/sbin/rpc.statd
svcgssd=/usr/sbin/rpc.svcgssd
mkdir_nfsdirs() {
local d
for d in /var/lib/nfs/{rpc_pipefs,v4recovery,v4root} ; do
[[ ! -d ${d} ]] && mkdir -p "${d}"
done
mount_pipefs() {
if grep -q rpc_pipefs /proc/filesystems ; then
if ! grep -q "rpc_pipefs /var/lib/nfs/rpc_pipefs" /proc/mounts ; then
mount -t rpc_pipefs rpc_pipefs /var/lib/nfs/rpc_pipefs
fi
fi
umount_pipefs() {
if [[ ${restarting} == "no" ]] ; then
if grep -q "rpc_pipefs /var/lib/nfs/rpc_pipefs" /proc/mounts ; then
umount /var/lib/nfs/rpc_pipefs
fi
fi
start_gssd() {
[[ ! -x ${gssd} || ! -x ${svcgssd} ]] && return 0
local ret1 ret2
${gssd} ${RPCGSSDDOPTS}
ret1=$?
${svcgssd} ${RPCSVCGSSDDOPTS}
ret2=$?
return $((${ret1} + ${ret2}))
stop_gssd() {
[[ ! -x ${gssd} || ! -x ${svcgssd} ]] && return 0
local ret
start-stop-daemon --stop --quiet --exec ${gssd}
ret1=$?
start-stop-daemon --stop --quiet --exec ${svcgssd}
ret2=$?
return $((${ret1} + ${ret2}))
start_idmapd() {
[[ ! -x ${idmapd} ]] && return 0
${idmapd} ${RPCIDMAPDOPTS}
stop_idmapd() {
[[ ! -x ${idmapd} ]] && return 0
local ret
start-stop-daemon --stop --quiet --exec ${idmapd}
ret=$?
umount_pipefs
return ${ret}
start_statd() {
# Don't start rpc.statd if already started by init.d/nfsmount
killall -0 rpc.statd &>/dev/null && return 0
start-stop-daemon --start --quiet --exec \
$statd -- $RPCSTATDOPTS 1>&2
stop_statd() {
# Don't stop rpc.statd if it's in use by init.d/nfsmount.
mount -t nfs | grep -q . && return 0
# Make sure it's actually running
killall -0 rpc.statd &>/dev/null || return 0
# Okay, all tests passed, stop rpc.statd
start-stop-daemon --stop --quiet --exec $statd 1>&2
waitfor_exportfs() {
local pid=$1
( sleep ${EXPORTFSTIMEOUT:-30}; kill -9 $pid &>/dev/null ) &
wait $1
case "$1" in
start)
# Make sure nfs support is loaded in the kernel #64709
if [[ -e /proc/modules ]] && ! grep -qs nfsd /proc/filesystems ; then
modprobe nfsd &> /dev/null
fi
# This is the new "kernel 2.6 way" to handle the exports file
if grep -qs nfsd /proc/filesystems ; then
if ! grep -qs "^nfsd[[:space:]]/proc/fs/nfsd[[:space:]]" /proc/mounts ; then
mount -t nfsd nfsd /proc/fs/nfsd
fi
fi
# now that nfsd is mounted inside /proc, we can safely start mountd later
mkdir_nfsdirs
mount_pipefs
start_idmapd
start_gssd
start_statd
# Exportfs likes to hang if networking isn't working.
# If that's the case, then try to kill it so the
# bootup process can continue.
if grep -q '^/' /etc/exports &>/dev/null; then
$exportfs -r 1>&2 &
waitfor_exportfs $!
fi
if [ -x $rquotad ]; then
start-stop-daemon --start --quiet --exec \
$rquotad -- $RPCRQUOTADOPTS 1>&2
fi
start-stop-daemon --start --quiet --exec \
$nfsd --name nfsd -- $RPCNFSDCOUNT 1>&2
# Start mountd
start-stop-daemon --start --quiet --exec \
$mountd -- $RPCMOUNTDOPTS 1>&2
stop)
# Don't check NFSSERVER variable since it might have changed,
# instead use --oknodo to smooth things over
start-stop-daemon --stop --quiet --oknodo \
--exec $mountd 1>&2
# nfsd sets its process name to [nfsd] so don't look for $nfsd
start-stop-daemon --stop --quiet --oknodo \
--name nfsd --user root --signal 2 1>&2
if [ -x $rquotad ]; then
start-stop-daemon --stop --quiet --oknodo \
--exec $rquotad 1>&2
fi
# When restarting the NFS server, running "exportfs -ua" probably
# isn't what the user wants. Running it causes all entries listed
# in xtab to be removed from the kernel export tables, and the
# xtab file is cleared. This effectively shuts down all NFS
# activity, leaving all clients holding stale NFS filehandles,
# *even* when the NFS server has restarted.
# That's what you would want if you were shutting down the NFS
# server for good, or for a long period of time, but not when the
# NFS server will be running again in short order. In this case,
# then "exportfs -r" will reread the xtab, and all the current
# clients will be able to resume NFS activity, *without* needing
# to umount/(re)mount the filesystem.
if [ "$restarting" = no ]; then
# Exportfs likes to hang if networking isn't working.
# If that's the case, then try to kill it so the
# shutdown process can continue.
$exportfs -ua 1>&2 &
waitfor_exportfs $!
fi
stop_statd
stop_gssd
stop_idmapd
umount_pipefs
reload)
# Exportfs likes to hang if networking isn't working.
# If that's the case, then try to kill it so the
# bootup process can continue.
$exportfs -r 1>&2 &
waitfor_exportfs $!
restart)
# See long comment in stop() regarding "restarting" and exportfs -ua
restarting=yes
svc_stop
svc_start
echo "usage: $0 {start|stop|restart}"
esac
exit 0