The problems with the Linux NFS export options crossmnt and nohide are documented in the Linux exports(5) man page:
> crossmnt > This option is similar to nohide but it makes it possible > for clients to move from the filesystem marked with crossmnt > to exported filesystems mounted on it. Thus when a child > filesystem "B" is mounted on a parent "A", setting crossmnt > on "A" has the same effect as setting "nohide" on B. > > nohide > This option is based on the option of the same name provided > in IRIX NFS. Normally, if a server exports two filesystems > one of which is mounted on the other, then the client will > have to mount both filesystems explicitly to get access to > them. If it just mounts the parent, it will see an empty > directory at the place where the other filesystem is mounted. > That filesystem is "hidden". > > Setting the nohide option on a filesystem causes it not to > be hidden, and an appropriately authorised client will be > able to move from the parent to that filesystem without > noticing the change. However, some NFS clients do not cope > well with this situation as, for instance, it is then > possible for two files in the one apparent filesystem to > have the same inode number. > > The nohide option is currently only effective on single > host exports. It does not work reliably with netgroup, > subnet, or wildcard exports. > > This option can be very useful in some situations, but it > should be used with due care, and only after confirming > that the client system copes with the situation effectively. > > The option can be explicitly disabled with hide. > Note the cautionary phrases: > However, some NFS clients do not cope > well with this situation as, for instance, it is then > possible for two files in the one apparent filesystem to > have the same inode number. > This option can be very useful in some situations, but it > should be used with due care, and only after confirming > that the client system copes with the situation effectively. Also note that the NFS client may get unexpected EXDEV errors for operations like rename(2) and link(2) if the source and destination for those operations are not on the same file system on the server. These errors will be unexpected on the client because the server is telling the client that they are all on one file system. HTH --macko
