+.IR 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
+.I 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.
+
+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
+.IR hide .
+.TP
+.IR no_subtree_check
+This option disables subtree checking, which has mild security
+implications, but can improve reliability is some circumstances.
+
+If a subdirectory of a filesystem is exported, but the whole
+filesystem isn't then whenever a NFS request arrives, the server must
+check not only that the accessed file is in the appropriate filesystem
+(which is easy) but also that it is in the exported tree (which is
+harder). This check is called the
+.IR subtree_check .
+
+In order to perform this check, the server must include some
+information about the location of the file in the "filehandle" that is
+given to the client. This can cause problems with accessing files that
+are renamed while a client has them open (though in many simple cases
+it will still work).
+
+subtree checking is also used to make sure that files inside
+directories to which only root has access can only be accessed if the
+filesystem is exported with
+.I no_root_squash
+(see below), even the file itself allows more general access.
+
+As a general guide, a home directory filesystem, which is normally
+exported at the root and may see lots of file renames, should be
+exported with subtree checking disabled. A filesystem which is mostly
+readonly, and at least doesn't see many file renames (e.g. /usr or
+/var) and for which subdirectories may be exported, should probably be
+exported with subtree checks enabled.
+
+The default of having subtree checks enabled, can be explicitly
+requested with
+.IR subtree_check .
+'''.TP
+'''.I noaccess
+'''This makes everything below the directory inaccessible for the named
+'''client. This is useful when you want to export a directory hierarchy to
+'''a client, but exclude certain subdirectories. The client's view of a
+'''directory flagged with noaccess is very limited; it is allowed to read
+'''its attributes, and lookup `.' and `..'. These are also the only entries
+'''returned by a readdir.
+'''.TP
+'''.IR link_relative
+'''Convert absolute symbolic links (where the link contents start with a
+'''slash) into relative links by prepending the necessary number of ../'s
+'''to get from the directory containing the link to the root on the
+'''server. This has subtle, perhaps questionable, semantics when the file
+'''hierarchy is not mounted at its root.
+'''.TP
+'''.IR link_absolute
+'''Leave all symbolic link as they are. This is the default operation.