搭建NFS服务器

NFS 是Network File System的缩写，即网络文件系统。一种使用于分散式文件系统的协定，由Sun公司开发，于1984年向外公布。功能是通过网络让不同的机器、不同的操作系统能够彼此分享个别的数据，让应用程序在客户端通过网络访问位于服务器磁盘中的数据，是在类Unix系统间实现磁盘文件共享的一种方法。

NFS在文件传送或信息传送过程中依赖于RPC协议。RPC，远程过程调用 (Remote Procedure Call) 是能使客户端执行其他系统中程序的一种机制。NFS本身是没有提供信息传输的协议和功能的。

NFS应用场景，常用于高可用文件共享，多台服务器共享同样的数据，可扩展性比较差，本身高可用方案不完善，取而代之的数据量比较大的可以采用MFS、TFS、HDFS等等分布式文件系统。

1. 环境准备两台Centos7.6虚拟机：

服务端：192.168.199.180

客户端：192.168.199.190

2.创建用户，指定用户访问共享文件夹：

useradd test   #创建test用户

                                   passwd   test  #设置test密码为123456

6.编辑nfs主配置文件/etc/exports；并添加以下内容：

/www  192.168.199.190(rw,sync,root_squash,no_all_squash,anonuid=1002,anongid=1002)     

参数详解：

NFS安装完毕，需要创建共享目录，共享目录在/etc/exports文件里面配置，可配置参数如下：

/www  192.168.199.190(rw,sync,root_squash,no_all_squash,anonuid=1002,anongid=1002)

第一列/www 表示需要共享的目录

IP表示允许哪个客户端访问

IP后括号里的设置表示对该共享文件的权限

ro                      只读访问

rw                      读写访问

sync                    所有数据在请求时写入共享

hide                    在NFS共享目录中不共享其子目录

no_hide                 共享NFS目录的子目录

all_squash              共享文件的UID和GID映射匿名用户anonymous，适合公用目录。

no_all_squash           保留共享文件的UID和GID（默认）

root_squash             root用户的所有请求映射成如anonymous用户一样的权限（默认）

no_root_squas           root用户具有根目录的完全管理访问权限

anonuid                 指定用户UID

anongid                 指定用户组ID

7.启动nfs服务：systemctl start nfs

8.查看nfs及rpc端口是否启动成功：

9. rpcinfo -p 192.168.199.180 查看，如图所示：

RPC命令详解： rpcinfo 命令会向 RPC 服务器发出 RPC 调用，并将得到的结果显示出来。rpcinfo 会列出所有在主机 host 上向 rpcbind 注册的 RPC 服务。

10. 使用showmount -e localhost 命令用于查询NFS服务器的相关信息，显示NFS服务器的输出清单。

11. 创建共享文件夹目录www 并在www目录下新建jfedu.txt并加入内容，授予www用户用户组的nfsnobody.nfsnobody权限

mkdir -p /www                       #创建www共享目录

touch  /www/jfedu.txt               #在www目录下创建jfedu.txt文件

chown  -R  test:test  /www  #授权用户用户组test给www目录

二、安装客户端：（192.168.199.190）

1. yum  install nfs-utils  -y

客户端上不需要启动nfs服务，只是为了使用showmount工具

2. 查看RPC端口是否启动：netstat -ntpl

3.使用showmount -e 192.168.199.180命令显示NFS服务器输出结果：

4.远程挂载www共享目录到客户端的/mnt目录下：mount -t nfs 192.168.199.180:/www /mnt

5. 进入到/mnt挂载盘符目录下cd /mnt  确认是否有jfedu.txt文件存在及查看文件权限属于谁：

确认文件已存在，用户用户组均为test用户所属，其他用户不能操作此目录下的文件及文件夹；包括root用户都不能操作删除及修改文件，例如root用户都不能删除jfedu.txt文件：

6.如果也只需要客户端的test用户去对www共享文件夹有增删改查权限的话，需要以下步骤：

a. 在客户端创建相同的test用户，并保证UID一致的情况下才能对共享目录有权限进行操作

b. 设置tets用户密码为123456

c. 查看test用户UID参数值是多少  cat /etc/passwd

d. 那么问题来了，服务端的test用户UID为1002，客户端test用户UID为1004，共享目录在客户端的权限也为1002，那么1004是没有权限去访问共享目录的，可参考下目前状态的错误图；首先切换到test用户,然后进入到/mnt目录下进行jfedu.txt文件删除看是否报错：

e. 经过测试同样的tets用户，但是客户端的用户UID跟服务端不一致，所以是没有权限删除文件的，首先退出tets用户，切换root用户后，需要修改客户端test用户UID跟服务端一致即可解决问题，命令：usermod -u 1002  tets

7.修改完客户端test用户UID为1002后，切换到test用户，查看是否有jfedu.txt文件存在；然后追加新内容123456到jfedu.txt中；最后新建123.txt文件成功，代表NFS共享目录指定用户读取（增删改查）成功。

8. 在NFS服务端把NFS跟RPC服务加入开机自启动：

systemctl enable nfs-server

systemctl enable rpcbind

9. 在客户端将NFS远程共享目录挂载命令加入fstab配置，不然服务器重启挂载点将消失，加入以下配置到/etc/fstab配置文件

192.168.199.180:/www     /mnt       nfs     defaults   0 0

服务器端需要安装 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 协议挂载，那么客户端挂载命令如下：

最后，卸载命令

---