One of the things that people traditionally ask for is an NFS server that can re-export its own NFS mounts (possibly among other things). Unfortunately this is impossible in general, and now I can explain why.

(In the old days, one reason people wanted this was because user level NFS servers were basically the only way to do user level filesystems at all, and it would be useful if your machine could transparently re-export your interesting user level filesystem to other machines. I'm not sure why people ask for this today.)

The core problem is that given only an NFS filehandle, the re-exporting server must both identify what real NFS server to pass the request to and recover the full original NFS filehandle to give that server. However, NFS filehandles are size-limited opaque blobs, all of which may be significant to the original NFS server; in general, there is no space to add your own identifier to a filehandle while being sure that you won't lose any information.

(If you are lucky, the NFS server that you are re-exporting uses short NFS v3 filehandles instead of full sized ones, leaving you enough space to glue the information you need on the front. Don't count on it, though.)

You can make up your own filehandle for every original filehandle that you re-export, but then you have to keep track of the mapping and do so in such a way that it persists over crashes and reboots. This is not impossible, but you're potentially going to be dealing with a lot of filehandles and NFS's statelessness means that you have no idea when clients have stopped using a particular filehandle.

(I suppose that this is less of an issue today, since NFS v3 filehandles are only at most 64 bytes long and disks get bigger every year; you can store a lot of mappings in a few gigabytes, and there are ways to revalidate and prune your database every so often.)