|
Prev: any test tool for dbus blackbox testing
Next: A new reader? Welcome to alt.os.linux, read this first if you're new here (FAQ)
From: linuxnewbie1234 on 24 Jun 2008 14:53 Hi all, today I had to re-export a NFS mount. That is, the machine mounts a NFS directory from an internal network, and has to export the same directory (or better a part of it) to an external network. nfs-kernel-server did not allow me to do that. It said Warning: <directoryname> does not support NFS export and then the client could not access. If I exported a parent directory, the client could access the share but then when cd'ing to the inner directory, it was presented as empty. It turns out that not all NFS filesystems can be exported. In particular NFS imports cannot apparently be re-exported!! (exactly which filesystems are supported I could not find it into the manpages) What was I supposed to do for re-exporting this? What I did is to use "unfs3": the user mode NFS v3 server. That one was able to export anything. But is it really guaranteed to work in the cases where the kernel server couldn't? What could be the problems? Thank you
From: J.O. Aho on 24 Jun 2008 16:13 linuxnewbie1234 wrote: > Hi all, > today I had to re-export a NFS mount. That is, the machine mounts a NFS > directory from an internal network, and has to export the same directory > (or better a part of it) to an external network. Reexport of NSf is never to recommend, better to let the external network to import the NFS share over a ssh tunnel. The reason is that things will not work properly, specially special files like file locks and so on. -- //Aho
From: linuxnewbie1234 on 25 Jun 2008 05:18 J.O. Aho wrote: > The reason is that things will not work properly, specially special > files like file locks and so on. Please elaborate on "and so on" because my knowledge is not enough to figure it out by myself. Any pointer appreciated. Is there any other means to have a remote mount, having full POSIX semantics? Performances are probably not a priority in our case (unless really terrible). Thank you
From: J.O. Aho on 25 Jun 2008 16:40 linuxnewbie1234 wrote: > J.O. Aho wrote: >> The reason is that things will not work properly, specially special >> files like file locks and so on. > > Please elaborate on "and so on" because my knowledge is not enough to > figure it out by myself. Any pointer appreciated. Whole your /dev, /sys and /proc are filled with different kind of special files, which in many cases aren't working well when exported in the first case and then bing re-exported they will be able to mess things up even more. You have symlinks, which works quite badly if you export those, as the importing file system may lack the file they are pointing at. There can also become trouble when writing files to the re-exported NFS share, as it in it's turn has to write back to the original NFS, this chain can cause a number of troubles, specially if a connection is lost in the chain and in worst case that can cause to a complete lock down. > Is there any other means to have a remote mount, having full POSIX > semantics? Performances are probably not a priority in our case (unless > really terrible). NFS over SSH tunnel http://www.math.ualberta.ca/imaging/snfs/ Already the SSH will slow things down, but it's a lot more sane way to export NFS than re-exporting. -- //Aho
From: linuxnewbie1234 on 2 Jul 2008 05:35
linuxnewbie1234 wrote: > Hi all, > today I had to re-export a NFS mount. ..... > What I did is to use "unfs3": the user mode NFS v3 server. That one was > able to export anything. Report: In the next days, we experienced a lot of problems with the setup above. The root user of the final client machine was able to see the imported files, but normal users were only seeing empty directories and getting "I/O Error"s. I don't know if it was because of an unfs3 bug or due to the re-export, but it wasn't working. Note that we had only normal data files, we didn't need locking, only one user was accessing each file at a time, there were no special files, there were no links etc. But it wasn't working anyway. At the end we had to export directly from the first server, pinholing the firewall, and using the in-kernel server. Thanks. |