NFS 提供了许多优点
NFS 在很大程度上是 Rick Sladkey 的工作成果，
他编写了 NFS 内核代码和 NFS 服务器的大部分代码。后者源自 Mark Shand 最初编写的 unfsd 用户空间 NFS 服务器，以及 Donald Becker 编写的 hnfs Harris NFS 服务器。
现在让我们看看 NFS 是如何工作的：客户端可以请求从远程主机挂载目录到本地目录，就像它可以挂载物理设备一样。但是，用于指定远程目录的语法是不同的。例如，要将主机 vlager 上的 /home 挂载到 vale 上的 /users，管理员将在 vale 上发出以下命令：
然后 mount 将尝试通过 RPC 连接到 vlager 上的 mountd 挂载守护进程。服务器将检查是否允许 vale 挂载所讨论的目录，如果允许，则返回一个文件句柄。此文件句柄将用于所有后续对 /users 下文件的请求。
当有人通过 NFS 访问文件时，内核会向服务器机器上的 nfsd（NFS 守护进程）发出 RPC 调用。此调用将文件句柄、要访问的文件的名称以及用户的用户 ID 和组 ID 作为参数。这些参数用于确定对指定文件的访问权限。为了防止未经授权的用户读取或修改文件，用户 ID 和组 ID 在两台主机上必须相同。
在大多数实现中，客户端和服务器的 NFS 功能都作为内核级守护进程实现，这些守护进程在系统启动时从用户空间启动。这些是服务器主机上的 NFS 守护进程 (nfsd) 和客户端主机上运行的块 I/O 守护进程 (biod)。为了提高吞吐量，biod 使用预读和写后执行异步 I/O；此外，通常同时运行多个 nfsd 守护进程。
的 NFS 实现略有不同，因为客户端代码紧密集成在内核的虚拟文件系统 (VFS) 层中，不需要通过 biod 进行额外的控制。另一方面，服务器代码完全在用户空间中运行，因此由于这会涉及同步问题，几乎不可能同时运行多个服务器副本。NFS 目前也缺乏预读和写后，但 Rick Sladkey 计划在将来添加此功能。
NFS 代码的最大问题是，版本 1.0 的内核无法分配大于 4K 的内存块；因此，网络代码无法处理大于大约 3500 字节的数据报，这在减去标头大小等之后。这意味着与默认使用大型 UDP 数据报的系统（例如 SunOS 上的 8K）上运行的 NFS 守护进程的传输需要人为地缩小尺寸。这在某些情况下会严重损害性能。 此限制在后期的 -1.1 内核中已消失，并且客户端代码已修改为利用这一点。