Hi, On Mon, Nov 27, 2006 at 07:15:28PM -0500, Josef Sipek wrote: > On Wed, Nov 22, 2006 at 11:51:20AM +0100, Michael Creel wrote: > > Hello to everyone, > > > > I'm adapting the ParallelKnoppix live CD to export home to the compute > > nodes via unionfs. This makes things very convenient, since a uniform > > set of files is available to all the nodes in the cluster. One the > > master node, the home dir is /UNIONFS/home/pk. This is nfs exported to > > the nodes using the following entry in /etc/exports: > > > > /UNIONFS/home/pk > > 192.168.0.0/255.255.255.0(rw,root_squash,fsid=42,async,no_subtree_check) > > > > > > This works fine with a 2.6.17 kernel and unionfs 1.3. However, with a > > 2.6.18 kernel and unionfs 1.4, the compute nodes can't mount the > > export, and the report the typical "reason given by server: permission > > denied" error. So I'm looking for pointers as to how to get this going > > with unionfs 1.4 (or I can switch to a 2.6.19 kernel and unionfs CVS, > > if that would help). > > If you don't mind runing latest kernels, using CVS snapshots is better. In > this case, there haven't been any changes since the 1.4 release (mostly due > to the fact that it was a rather late release.) > > Besides that, it is really odd that it doesn't work with 2.6.18. Looking at > the Unionfs changelog I don't see anything that would make it not work like > that. We'll try to reproduce it here in the lab...
Could you look into dmesg at the server (!) side? If you see a kernel oops caused by nfsd when accessing /var/lib/nfs/v4recovery, this may be the reason why your clients are not able to access the (defective) server anymore. Solution, until this is fixed in unionfs: mount -t tmpfs none /var/lib/nfs/v4recovery before starting nfsd. Regards -Klaus Knopper _______________________________________________ unionfs mailing list [email protected] http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs
