必须为设备上的每个文件系统提供唯一的挂载点来充当文件系统数据的访问点。可以为项目提供挂载点，但是这些挂载点仅作为一个工具使用继承的属性来管理名称空间。项目从不挂载，且不通过任何协议导出数据。
所有共享资源必须挂载在 /export 下。虽然可以创建挂载在 /export 下的文件系统，但是没有必要。如果不存在这样的共享资源，则将根据需要在此层次结构部分中动态创建任意目录。每个挂载点在群集中必须是唯一的。
名称空间嵌套挂载点－可以在一个文件系统下创建带有挂载点的其他文件系统。在这种情况下，应先挂载父文件系统，再挂载子文件系统，反之亦然。使用嵌套的挂载点时应考虑以下事项：
如果挂载点不存在，将创建一个挂载点，由 root 和模式 0755 所拥有。在重命名、销毁或移动文件系统时，此挂载点可能会也可能不会被卸载，视情况而定。为安全起见，应在创建子文件系统之前在父共享资源中创建挂载点。
如果父目录是只读的，且挂载点不存在，则文件系统挂载将失败。这种情况可能会在创建文件系统时同步发生，但也可能会在进行大规模更改（例如使用继承挂载点重命名文件系统）时异步发生。
重命名文件系统或更改其挂载点时，当前挂载点下的所有子挂载点以及新挂载点（如果不同）将被卸载并在应用更改后被重新挂载。这将中断当前访问共享资源的任何数据服务。
如下面所概述，是否支持自动遍历嵌套挂载点取决于协议。
名称空间 NFSv2/NFSv3/NFSv4.0/NFSv4.1－在 NFS 下，每个文件系统是可通过 MOUNT 协议设为可视的一项独特导出内容。NFSv2 和 NFSv3 无法遍历嵌套文件系统，必须通过文件系统的完整路径来访问每个文件系统。虽然嵌套挂载点仍可起作用，但是尝试遍历嵌套挂载点将会导致客户机上显示空目录。虽然通过使用自动挂载方式进行挂载可以缓解这种现象，但是在动态环境中透明支持嵌套挂载点则需要使用 NFSv4.0 或 NFSv4.1。
相较于 NFSv3，NFSv4.0 和 NFSv4.1 在处理挂载点时进行了多项改进。首先是，可以挂载父目录，即使分层结构中该挂载点没有可用共享资源也是如此。例如，如果共享了 /export/home，则可以在客户机上挂载 /export，并透明地遍历到实际的导出内容。更为重要的是，某些 NFSv4.0 和 NFSv4.1 客户机（包括 Linux）支持自动客户端挂载，有时称为“镜像挂载”。使用这样的客户机，当用户遍历某个挂载点时，子文件系统将自动挂载到相应的本地挂载点，并且当文件系统在客户机上被卸载时也同时卸载。从服务器的角度来看，这些是单独的挂载请求，但在客户机中它们缝合在一起以形成无缝的文件系统名称空间。
名称空间 SMB－SMB 协议不使用挂载点，因为通过资源名称来使每个共享资源变为可用。但是，每个文件系统必须仍具有唯一挂载点。当前不支持嵌套挂载点（一个资源内有多个文件系统），任何遍历挂载点的尝试将会导致显示空目录。
名称空间 FTP/FTPS/SFTP－使用文件系统的标准挂载点导出文件系统。完全支持嵌套挂载点，并且这些挂载点对于用户透明。但是，不能在嵌套文件系统的父文件系统处于共享状态时不共享嵌套文件系统。如果共享父挂载点，则也将共享所有子挂载点。
名称空间 HTTP/HTTPS－文件系统导出在 /shares 目录下，因此 /export/home 下的文件系统将通过 HTTP/HTTPS 显示在 /shares/export/home 下。完全支持嵌套挂载点，并且这些挂载点对于用户透明。FTP 协议部分所述的有关共享资源选项冲突的相同行为也适用于 HTTP。