NFS failure (more) (was Re: [plug] SIGHUP woody nfs)

[Beau Kuiper]

Hmm,

My notes about nfs.

I have always found the user space nfs server to be more reliable than the 
kernel space nfs server (but I haven't tried it on a late 2.2 or late 2.4 
kernel), and not much slower. In particular, when more than one client is 
accessing the nfs server, the 2.4.5 kernel server tends to hang clients, 
while the user space version keeps trucking.

The user space nfs server may be difficult to compile on modern distributions 
(like slackware 8), due to header changes. This can ussually be fixed by 
fudging things around though.

Another important this is that you must run rpc.portmap on BOTH the client 
and server (don't ask me why)

On that tone, make sure your hosts.allow and hosts.deny are correct. It may 
also make sense to use the firewall to block access to the portmapper from 
anywhere it isn't needed. For clients, only localhost should be able to 
access their portmapper, and only the clients should be able to access the 
server portmapper.

One more thing, make sure you run the mountd installed by the user space nfs 
domain when using the user space nfs domain, rather than the kernel space 
mountd. I found it useful to install the user space nfs libraries in a 
different directory (like /usr/lib/unfsd) and have an init.d script run it 
directly from there so things don't become confused.

Your exports file looks fine though.

Beau Kuiper
kuiperba at cs.curtin.edu.au


On Saturday 29 December 2001 22:17, Harry McNally wrote:
> A hint for the unwary .. (sorry for the never-ending-story) ..
>
>  >I apt-get installed nfs-user-server a user space nfs that uninstalled
>  > nfs-kernel-server and started the user server.
>  >
>  >Now an nfs mount attempt at the potato box being installed gives:
>  >reason given by server: Permission denied.
>
> For woody users moving between nfs-kernel-server and nfs-user-server I
> _think_ I've found that /etc/exports needs to change when you install the
> other.
>
> Using nfs-kernel-server the /etc/exports was:
>
> /cdrom 192.168.1.0/24(ro)
>
> (which worked) whereas for nfs-user-server the server rejects requests from
> 92.168.1.69 (Permission denied, as explained above). I found I had to rely
> on a server /etc/hosts entry for 192.168.1.69 (no dns here) and change the
> /etc/exports to reflect the clients hostname (debian) thus:
>
> /cdrom debian(ro)
>
> By running server rpc.mountd in foreground using:
>
> # /usr/sbin/rpc.mountd -F -d auth
>
> I get:
>
> mountd[460] 12/29/101 21:21 auth_forward_lookup(debian) debian
> mountd[460] 12/29/101 21:21 clnt debian exports:
> mountd[460] 12/29/101 21:21     /cdrom
> mountd[460] 12/29/101 21:21             options: ro noroot portck
> mountd[460] 12/29/101 21:22 flushed host access cache
> mountd[460] 12/29/101 21:22 NFS mount of /cdrom attempted from 192.168.1.69
> mountd[460] 12/29/101 21:22 auth_path(/cdrom): mount point /cdrom,
> (root_squash secure ro)
> mountd[460] 12/29/101 21:22 /cdrom has been mounted by 192.168.1.69
>
> Server is happy but the client _now_ fails with:
>
> Mounting 192.168.1.9:/cdrom on /instmnt failed: Invalid argument
>
> arrgh
>
> man exports ..