Ubuntu 16.04 搭建 NFS 文件共享服务器

服务器端需要安装 nfs-kernel-server 软件包：

$ sudo apt-get update

$ sudo apt-get install nfs-kernel-server

默认情况下，NFS 服务器上定义了某个共享目录，则该目录及其子目录下的所有文件都可被访问。

出于对安全的考虑，客户端任何需要 超级用户 （即 root 用户，UID=0 &GID=0）权限的文件操作都默认映射到 UID=65534 和 GID=65534 的用户，即 Ubuntu 系统中的 nobody:nogroup。

例如客户端使用 root 权限在挂载的共享目录中创建文件时，该文件的 属主 和 属组 自动变为 nobody:nogroup ，而非 root:root 。

sudo mkdir -p /var/nfs/gernel

sudo mkdir -p /var/nfs/public

sudo chown nobody:nogroup /var/nfs/gernel

为了使 NFS 服务器定义的共享文件可被指定的客户端主机访问，需要在服务器端的 /etc/exports 文件中添加对应的记录。

该文件的格式如下：

Directory Host(Options ...) Host(Options) #comment

关于 /etc/exports 文件的详细语法格式可参考 man exports 。

文件示例：

列出 nfs 服务器上的共享目录

创建挂载点

sudo mkdir -p /mnt/nfs/gernel

sudo mkdir -p /mnt/nfs/public

sudo mkdir -p /mnt/nfs/starky

挂载远程目录

sudo mount 192.168.56.102:/var/nfs/gernel /mnt/nfs/gernel

sudo mount 192.168.56.102:/var/nfs/public /mnt/nfs/public

sudo mount 192.168.56.102:/home/starky /mnt/nfs/starky

权限测试

NFS 的权限设定基于 Linux 文件系统的权限管理，即客户端挂载远程共享目录后，会把它们当成本地磁盘目录一样对待，也是根据文件的属主（组）及其对应的权限设定来限制访问。

gernel 目录的属主（组）为 nobody:nogroup（65534:65534），所以虽然该目录为读写权限，非 root 用户无法执行新建操作。而 root 用户由于 NFS 默认的安全机制，会自动映射到 nobody:nogroup。

由于我在客户端和服务端都有一个名为 starky 的用户，且它们的 UID:GID 都为1000:1000，所以服务端的 /home/starky 目录可以直接被客户端的 starky 用户访问。且由于 no_root_squash 选项，通过 sudo 命令创建的文件其属主仍为 root（而不会再映射为 nobody）。

当然这会导致一些安全问题，比如多个客户端同时都有 UID（GID）为1000的用户（不管用户名是什么），则这些用户会共享服务端 /home/starky 目录里的文件权限。

可编辑 /etc/fstab 文件令挂载共享目录的 mount 操作成为系统的固定配置（手动输入的 mount 命令属于临时挂载，重启会自动卸载），使得系统重启后可以自动挂载远程文件系统。 /etc/fstab 文件的示例内容如下：

/etc/exports 文件的格式为： Directory Host(Options ...) Host(Options) #comment

其中的 Host 项用来指定可访问对应共享目录的主机，其格式可分为以下几种：

传输协议

最初的 NFSv2 由于性能原因使用 UDP 协议，虽然 NFS 添加了自己的 包序列重组 和 错误检查 功能，但 UDP 和 NFS 都不具备 阻塞控制 算法，所以在大型的互联网络环境中缺乏足够的性能。

NFSv3 提供了 UDP 和 TCP 协议之间的选择。NFSv4 只能使用 TCP 协议。

随着 CPU，内存等硬件设备和网络传输速度的提高，最初由于性能需求而倾向 UDP 协议的选择也变得不再必要。

State

NFSv2 和 NFSv3 是 无状态 的连接，服务端不会跟踪客户端对共享目录的挂载情况，而是使用 "cookie" 来记录一次成功的挂载。"cookie" 不会因为服务器重启而删除，可以用来在服务器挂掉之后保留客户端的连接信息。

NFSv4 是 有状态 的连接，客户端和服务端都会维护文件操作纪录及文件锁的状态。所以不再需要 "cookie" 的使用。

文件锁

早期版本的 NFS 协议（v2 &v3）由于是 无状态 的连接，它们并不清楚哪些主机正在使用哪些文件。但是文件锁的实现又需要获取状态信息。所以早期协议中的文件锁是独立于 NFS 实现的。

而 NFSv4 将文件锁的实现整合到了核心协议中，虽然此举增加了复杂度，但同时也解决了早期版本中的很多问题。

但是为了兼容使用 V2 和 V3 协议的客户端，独立的 locked 和 statd 守护进程仍旧需要。

安全相关

NFS 协议最初在设计时并不关注安全性，NFSv4 通过引入对更强大的安全服务和身份验证的支持，加强了该协议的安全性。

传统的 NFS 协议大多使用 AUTH_SYS 验证方式，基于 UNIX 的用户和组标识。在这种方式下，客户端只需要发送自己的 UID 和 GID 并与服务器上的 /etc/passwd 文件内容作对比，以决定其拥有怎样的权限。

所以当多个客户端存在 UID 相同的用户时，这些用户会拥有相同的文件权限。更进一步，拥有 root 权限的用户可以通过 su 命令切换到任意 UID 登录，服务器会因此给予其对应 UID 的权限。

为了防止上面的问题出现，服务器可选择使用更健壮的验证机制比如 Kerberos 结合 NFS PRCSEC_GSS。

NFS 共享目录的访问控制基于 /etc/exports 文件中定义的主机名或 IP 地址。但是客户端很容易针对其身份和 IP 地址造假，这也会导致一些安全问题。

NFSv4 只使用 TCP 作为自己的传输协议，而且通常只开放 2049 端口进行数据传输。在配置防火墙时，除了放开 2049 端口的限制外，还要时刻注意数据传输的源地址和目标地址。

win10 系统默认不能挂载 NFS 共享目录，需要进入 控制面板 - 程序 - 程序和功能 - 启用或关闭 Windows 功能 ，勾选上 NFS 服务 。

UNIX and Linux System Administration Handbook, 4th Edition

How to Mount an NFS Share Using a Windows 10 Machine

NFS（Network File System），网络文件存储系统，它最早是由 Sun 公司开发的，也是 FreeBSD 支持的文件系统中的一个，它允许网络中的计算机之间通过TCP/IP 网络共享资源。通过 NFS 协议，我们本地 NFS 的客户端应用可以透明的读写位于服务端 NFS 服务器上的文件，就像访问本地文件一样方便。简单的理解，NFS 就是可以透过网络，让不同的主机，不同的操作系统可以共享存储的服务。

NFS 在文件传送或信息传送过程中依赖 RPC（Remote Procedure Call）协议，即远程过程调用，NFS的各项功能都必须向 RPC 来注册，如此一来 RPC 才能了解 NFS 这服务的各项功能 Port，PID，NFS 在服务器所监听的 IP 等，而客户端才能透过 RPC 的询问找到正确对应的端口，所以 NFS 必须要有 RPC 存在是才能成功的提供服务，简单的理解二者关系：NFS 是一个文件存储系统，而 RPC 是负责信息的传输。

通过上面的简介，我们知道 NFS 服务需要依赖 RPC 服务，所以这里 NFS 服务端需要安装 rpcbind 和 nfs-utils ，客户端只需要安装 nfs-utils 即可，由于我们选用 CentOS 系统，所以可以使用 yum 快速的安装。

然后安装 NFS 服务

另：Ubuntu 16.04 安装命令

我们在服务端创建一个共享目录 /data/share ，作为客户端挂载在远端入口，然后设置权限

然后，修改 NFS 配置文件 /etx/exports

说明一下，这里配置后边有很多参数，每个参数有不同的含义，具体可以参考下边。此处，我配置了将 /data/share 文件目录设置为允许IP为 192.168.0.0/24 区间的客户端挂载。然后，如果客户端IP不在该区间也想要挂载的话，可以设置IP区间更大或者设置为 * 即允许所有客户端挂载，例如： /home *(ro, sync,insecure,no_root_squash) 设置 /home 目录允许所有客户端只读挂载。

接下来，我们先启动 RPC 服务

我们发现，启动了 NFS 服务后，RPC 注册的端口列表明显增多。现在服务端都启动起来了，在服务端看下是否正确加载了设置的 /etc/exports 配置

最后，在另一台Linux虚拟机上测试一下，是否能够正确挂载。首先，我们可以在客户端查看下NFS服务端设置可共享的目录信息

然后，在客户端创建挂载目录/share

最后，挂载远端目录到本地 /share 目录

可以看到，可以正确将远端 NFS 目录挂载到本地。注意：挂载点 /share 目录必须已经存在，而且目录中没有文件或子目录

最后，我们在 NFS 服务端 /data/share 目录下创建一个文件，看下客户端能否正确读取并修改

都可以了，这里因为上面设置了 NFS 远端目录权限为 rw 拥有读写权限，如果设置为 ro ，那么客户端只能读取，不能写入。根据实际应用场景合理配置。

NFS 默认使用 UDP协议进行挂载，为了提供 NFS 的稳定性，可以使用 TCP 协议挂载，那么客户端挂载命令如下：

最后，卸载命令

---