NFS export of unsupported filesystems (e.g. NFS re-export)
linuxnewbie1234
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
J.O. Aho
> 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
linuxnewbie1234
> 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
J.O. Aho
> 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
linuxnewbie1234
> 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.