Unfortunately no one can be told what fun_plug is - you have to see it for yourself.
You are not logged in.
Hi forum
I used to use fonz unfsd for nfs server, by default export /, /mnt/HD_a2 and /mnt/HD_b2. Everything works fine.
Now, I'm moving to chroot debian (downloaded etch from forum) for svn support, and want to move nfs server to debian one as well.
Use same configuration (except format of IP address, in unfsd I can use: 192.168.1.0/24, but in debian, I had to use 192.168.1.0/255.255.255.0. But I don't think this make any different) "/" and "/mnt/HD_b2" export is fine, when I try to mount "/mnt/HD_a2", I got "Stale NFS file handle" error. I tried restart nfs server, reboot client, mount to another point (same point mount "/" is fine), nothing work. I tried two different Linux box (CentOS and Fedora 7), and all get same error. (I used to mount "/mnt/HD_a2" when use unfsd nfs server on both client boxes).
I searched internet, most of them said this is client side issue, but since I'm getting same error from both clients, I'm not very sure. BTW, switch back to unfsd still works like a charm.
Any idea?
Thanks
Noodle
Offline
Hello
Personally, I use both Fonz's fun_plug and Debian etch, but I kept nfs on the first one (ie. not chrooted). If you use nfs in the chrooted environment, you cannot export /mnt/HD_a2, because your root directory is not there, but rather in /mnt/HD_a2/etch, which now stands for "/". Is this your problem?
Offline
I'm not sure if this is the problem. Because /mnt/HD_a2 is mounted as /mnt/HD_a2/etch/mnt/HD_a2 as well. In another word, /mnt/HD_a2 still available in chroot environment, and it point to same location. But I think you may right, it's a infinite loop, like /mnt/HD_a2/etch/mnt/HD_a2/etch/mnt/HD_a2/etch/......., end less. Could this occured problem in NFS?
Yes, I will use fonz's unfsd for nfs server. Thanks for advice.
Offline
Hum, I'm not sure it's a good idea to "loop" mount directories.. I would not do it.
Offline
Yes, verified, NFS under chroot mode has problem.
I tried to move etch from disk1 to disk2, now when I try to mount disk2, I got Stale file handle error, even for subfolders in disk2. So, if you want to more capability of NFS, you need to use Fonz unfsd instead of the one from chroot Debian.
Offline
I have the same issue with my Debian chroot: NFS seems to crash after during the boot process
Here is the output of dmesg (from Debian chroot):
[...]
svc: failed to register lockdv1 RPC service (errno 97).
NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory
NFSD: unable to find recovery directory /var/lib/nfs/v4recovery
NFSD: starting 90-second grace period
nfsd: last server has exited, flushing export cache
svc: failed to register lockdv1 RPC service (errno 97).
NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory
NFSD: unable to find recovery directory /var/lib/nfs/v4recovery
NFSD: starting 90-second grace period
I noticed that after a reboot, the NFS shares do work, at least for 60 seconds... It seems something makes the nfs server crash later (maybe during the chroot)
I managed to watch the export list (NFS shares) from another PC with the command "showmount -e nas"
When the NFS server crashes, the /etc/exports file inside the firmware is cleared, which explains why restarting NFS server from the DLink menu does not work.
To successfully restart NFS:
1) in DLINK firmware, disable NFS (clear the /etc/exports file)
2) Restore a backup of the /etc/exports (located at /mnt/root/etc/exports from the chroot)
3) in DLINK firmware, enable NFS
You're done, NFS is back. The only issue is that shares are not visible in the Dlink interface but you can still mount them.
The command "showmount -e nas" confirms the NFS server is running.
Now we have to figure out why the NFS server crash during startup, if the debian chroot is enabled...
I also agree about the infinite loop, which can cause the NFS server to crash
From the firmware side, RAID is mounted on /mnt/HD/HD_a2
The debian chroot is physically located in /mnt/HD/HD_a2/debian (in my case)
The Debian fun_plug script is also mounting the RAID array (bind) on the Debian chroot (so that the disks are available inside the chroot) in /mnt/HD/HD_a2/debian/mnt/HD/HD_a2
This implies a kind of loop, because the RAID array (which contains the debian chroot) is mounted inside the chroot
/mnt/HD/HD_a2/debian/mnt/HD/HD_a2
/mnt/HD/HD_a2/debian/mnt/HD/HD_a2/debian/mnt/HD/HD_a2
/mnt/HD/HD_a2/debian/mnt/HD/HD_a2/debian/mnt/HD/HD_a2/debian/mnt/HD/HD_a2
and so on...
Maybe the solution would be to move Debian to a USB key?
Offline