鹏叔(https://pengtech.net)

导航

CentOS7搭建NAS文件共享存储

目录

1. 前言

1.1. 网络存储技术

网络存储技术大概可以分为3种：

  • DAS：直连式存储（Direct Attached Storage），直接与主机相连的存储设备。它依赖于服务器，本身是硬件的堆叠，不带有任何存储操作系统。现在常见的DAS设备：硬盘座带上 N个硬盘。

  • NAS：网络连接式存储（Network Attached Storage），存储设备直连网络，NAS设备和DAS设备不同在于，NAS设备一般带有存储操作系统。

  • SAN：存储网络（Storage Area Network），可以说是一种网络基础设施。SAN和NAS的区别主要在于：SAN针对海量、面向数据块的数据传输，而NAS则提供文件级的数据访问功能。

2. NAS

网络附加存储（Network Attached Storage，NAS）是连接到一个局域网的基于IP的文件共享设备。NAS设备是专用的、高性能的、高速的、单一用途的文件服务和存储系统。NAS设备使用自己的操作系统和集成的硬件、软件组件，满足特定的文件服务需求。NAS设备在通用服务器的基础上进行了优化，比如文件服务功能、存储、检索、访问应用程序管理的客户端文件。

在过去几十年里，IT江湖从来都是门派林立，纷争不断。如果按照Operating System (下面简称OS), 大概可以分Windows派，Linux派，还有FreeBSD派。这几大门派信徒众多，教规又各不相同，所以经常造成矛盾。比如说，你要共享一个文件系统，Windows派喜欢用CIFS访问，Linux派习惯用NFS访问，近年来如日中天的苹果派(FreeBSD)们则用AFP。为了伺候好这些门派，NAS就需要支持多种共享协议。

2.1. NAS设备包含如下组件

  1. NAS引擎(CPU和内存等)
  2. 一个或多个网络接口卡（NIC），提供网络连接。如千兆以太网卡、万兆以太网卡
  3. 一个优化的操作系统用于NAS功能管理
  4. 文件共享协议NFS和CIFS
  5. 采用工业标准存储协议的磁盘资源，如ATA、SCSI、FC
  6. 用来访问NAS设备的客户端。

2.2. NAS支持的协议介绍

  1. CIFS (Common Internet File System protocol)
    工作在OSI模型的应用/表示层，常用于微软操作系统，但是与平台无关。CIFS运行在TCP/ IP上，使用DNS（域名服务）进行名称解析
    CIFS其中包含的状态协议提供如下两个功能：
    （1）在客户端应用程序具备恢复连接功能时，可以自动恢复连接和重新打开被中断的文件。
    （2）在客户端应用程序不具备自动连接功能时，用户则必须重新建立CIFS连接

  2. NFS (Network File System protocol)

    NFS的全称是Network File System，即网络文件系统。它使一台电脑可以通过网络访问另外一台电脑上的共享，使用起来就如同本地文件系统一样方便。
    NFS的开发者就是曾经名震江湖的SUN公司，它已经在2009年被甲骨文收入门下。SUN把NFS的第一个版本NFSv1藏在深闺，就像古墓里的小龙女，从不露面。在江湖上开始流行的是第二版NFSv2了。NFSv2很好用，但是问题也不少，比如它不支持大于2GB的文件，但这在90年代之前还不是大问题。令人费解的是，虽然NFSv3在1995年就面世了，但到今天还有人坚持用NFSv2。其实NFS可以工作在任何OS上。只不过因为OS门派之别，一般只在Linux环境中使用。目前广泛应用的版本还是NFSv3,我们有机会再另文讨论NFSv4。下图展示了多台客户端通过NFS对NAS的访问。
    NFS server client diagram

    NAS在这里充当了NFS服务器的角色，而Linux，Solaris和AIX则是NFS客户机。

  3. AFP（Apple Filing Protocol ）
    AFP是一种专门为 MAC OS X 系统提供文件共享服务的协议，通过开源的 Netatalk 实现 AFP 共享。mac os 物理接口是 雷电 thounderbolt ,协议就是 AFP.

3. NFS服务详解

NFS的功能很多，不同的功能对应着不同的daemon。比如一定要有的nfsd和mountd，还有可选的lockd和statd。
每个daemon都需要占用一些端口，但有些daemon是可选的，也许用户根本不会启用它们。所以，NFS并没有给每个NFS daemon保留固定端口(除了nfsd)。而是在系统启动时给需要启用的NFS daemon分配端口，然后把这些端口号告诉RPC daemon。RPC daemon的端口号是固定的111，每个NFS客户机都知道怎么联系它。当客户机需要连接NFS的某个daemon时，就不得不先咨询RPC daemon，获得该NFS daemon对应的端口号，然后再发送NFS请求。

3.1. NFS连接的建立过程

我第一次看到RPC daemon的工作原理，就想起交大管浴室的老头。他的固定地址是门房(相当于端口111)，每个要洗澡的学生(NFS客户机)都知道怎么找到他，他会给你一个带号码的钥匙(端口号)，有了这个号码，你就可以找到相应的格子(NFS daemon)放衣服了。

物理视图
nfs connecting flow phisical view

交互视图
nfs connecting flow

  1. 首先服务器端启动RPC服务，并启动portmapper监听在RPC服务的111端口

  2. 服务器端启动NFS服务，并向portmapper注册端口信息

  3. 客户端启动RPC（portmapper服务），向服务端的RPC(portmapper)服务请求服务端的NFS端口

  4. 服务端的RPC(portmapper)服务反馈NFS端口信息给客户端。

  5. 客户端通过获取的NFS端口来建立和服务端的NFS连接并进行数据的传输。

3.2. NFS各服务介绍

3.2.1. portmapper (rpcbind)

它响应RPC服务的请求和与请求的RPC服务建立连接.
入口服务portmapper，它一般监听在111端口，起的作用有点类似现代的服务注册与发现的功能——客户端首先连上它，询问nfs、mountd、nlockmgr等服务监听的端口，有了端口号后才能与对应的服务打交道。

portmapper 和 rpcbind的关系

portmapper从nfs v3,4版本开始叫做 rpcbind。 通过下面的命令可以看到portmap或者叫rpcbind中记录的内容：

3.2.2. nfs

最主要的NFS服务提供程序，这个daemon主要的功能就是管理客户端是否能够使用服务器文件系统挂载信息，其中还包含判断这个登录用户的ID。

3.2.3. rpc.mountd

这个daemon主要功能则是管理NFS的文件系统。当client端顺利通过rpc.nfsd登入主机后，在它可以使用NFS服务器提供规定文件之前，还会经过文件使用权限的认证程序。它会去读取NFS的配置　　文件/etc/exports来对比客户端的权限，当通过这一关之后，client端也就取得使用NFS文件的权限。

3.2.4. rpc.statd(可选)

这个daemon可以用来检查文件的一致性，若发生因为客户端同时使用同一个文件造成文件损坏时，rpc.statd可以用来检测并尝试恢复该文件

4. NAS服务器安装

了解以上一些概念后我们可以着手安装支持NFS协议的NAS服务器. 对于支持CIFS,和AFP协议的服务器不在本教程范围内.

4.1. 安装软件

4.1.1. 服务端安装nfs-utils、rcpbind软件包

这里以Centos操作系统为例

yum -y install nfs-utils rpcbind

4.2. 配置NAS

4.2.1. 配置nfs服务端口

配置文件位于 /etc/sysconfig/nfs

设置各种*port=...参数

# TCP port rpc.lockd should listen on.
LOCKD_TCPPORT=32803
# UDP port rpc.lockd should listen on.
LOCKD_UDPPORT=32769

# Port rpc.statd should listen on.
STATD_PORT=662
# Outgoing port statd should used. The default port is random
STATD_OUTGOING_PORT=2020

既然涉及到端口, 就要确保防火墙没有屏蔽以上端口, 否则的话, 客户端和服务器端无法建立连接.

下表列举了一些NFS服务器的端口：

端口号 服务
32803/32769 rpc.lockd
662 status
111 portmapper
20048 mountd
2049 nfs/nfs_acl

4.2.2. 配置文件共享

创建共享目录：

mkdir /shared
chmod 777 /shared

注意:初次配置NAS 建议将权限设置为777, 有助于顺利测试后续的挂载, 测试读取,创建,删除,修改文件, 但是这样设置是有安全风险的, 后续熟悉了用户身份映射再回来设置合适的权限. 另外此处我以root用户身份创建的/shared目录, 所有共享目录的owner也是root, 后续等弄明白了身份映射, 也建议回头把owner改为合适的owner. 当前阶段因为权限设置为了777, Owner也不是重点, 不影响将整个流程走通.

设置共享文件权限

sudo vi /etc/exports
#添加如下内容
/shared 192.168.0.0/16(rw,root_squash,all_squash,sync,anonuid=1000,anongid=1000)

加载NFS配置, 使权限生效

sudo exportfs -r
4.2.2.1. 权限说明

初次看到这么一长串其实挺令人费解的, 这些都是什么鬼, 除了rw比较熟悉一点,猜也能猜出来是可读写以外, 其他都是一头雾水.

这里其实不必太纠结, 直接设置为最开放的权限 /shared *(rw) 继续往后走好了, 后续也不会遇到一些莫名其妙的问题, 把流程走通最重要, 后续再回头来将设置调精细, 尤其是初次配置NAS, 这样设置可以避免很多坑, 以免将自己弄得很沮丧.

当你回头来调参数的时候,就需要了解以下内容了.

第一点: NAS 客户端是不需要登陆即可访问共享目录的, 哪服务器端如何知道访问者是谁,访问者该拥有多大权限的呢?

答案就是通过ip 地址和客户端的当前用户id, 和组id , 通过IP 控制是否能访问NAS服务, 通过用户ID控制能访问什么文件, 有多大权限, 当然这种简单的权限控制模型会有缺陷, 要做到相对安全也要看个人的配置能力,以及对NFS的理解程度.

这里我在/etc/exports文件中指定的是一个网段192.168.0.0/16, 什么意思呢? 也就是这个网段的用户可以访问NAS上的此目录, 当然也可以按单个ip地址配置, 可以将网段替换为ip地址, 这样就只有指定ip地址的用户可以访问共享目录这样就精细化了很多, 当然 ip地址是容易伪装, 替换, 以及变化的, 这就是NAS 权限控制比较理想化的地方, 如果是在局域网内,就看管理员如何控制好ip地址的分配, 路由设置等水平了, 所以安不安全要看管理员的水平. 这里也可以配置为通配符, 例如 *, 任何ip过来的用户都可以访问.

刚刚讲到了 ip 地址是NAS 权限控制的重要因子, 另外客户端uid, gid 也是权限控制的重要因子, NAS很好的利用了Linux的权限管理模型, 对熟悉Linux/Unix的系统的用户也降低了学习难度. 首先假设这里配置是no_root_squash, no_all_squash, 这两个选项是什么意思? 先简单介绍这两个选项的作用, 就是不要做身份映射, 简单来说就是, 如果客户端当前是 root用户, 那么他访问共享目录的身份就是root, (当然是不是 root 用户是取决于他的用户id, 而不是用户名, 我们知道所有的linux root 用户的ID都是0, 所属组ID是0, 这里为了便于描述使用用户名代表root用户) , 如果是普通用户 例如zhangsan (uid:999), 那么他操作共享目录的身份就是zhangsan, 那么张三有什么样的权限呢? 还记得我们创建共享目录的时候设置了什么样的访问权限吗? chmod 777 /shared, 张三不是owner, 不属于root组, 张三应该属于others(其他用户) , others对该目录用户读写执行权限. 假设我们创建共享目录的时候是这样 chmod 770 /shared, 那么张三是没有任何权限, 对目录中的文件及文件夹不能进行任何操作. 这就是我为什么在创建共享目录的时候建议大家先授予目录777权限, 权限似乎大的吓人, 但是后续就好发现它的好处, 因为我们在客户端配置,测试的时候, 往往可能就是其他用户, 不是root, 也不属于root的用户, 尤其在windows上访问NAS.

从以上的描述, 不知道各位看官有没有发现一个问题或者叫漏洞( 我担心在本已很复杂的逻辑,再引入一个复杂的问题, 会让人晕掉,所以前面只字未提这个, 现在另起一段来讨论这个问题). 这里先假设客户端有个叫zhangsan(uid:999) 的用户, 服务器端也有zhangsan(uid:999) 的用户, 那很好啊,客户端的张三就像服务器端的张三一样读或写共享目录.接下来的问题就复杂一些了, 假设服务器端压根就没有 zhangsan(uid:999) 的用户, 连uid为999的用户都没有, 那会怎样? 大家可以把流程走通后自己测试一下, 我已经测试过了, 张三依然能访问目录, 而且当张三创建新文件的时候, 会创建一个uid:999的文件, 当我ls -lt 查看此文件的时候, 只能看到文件的 owner是999, 不会显示owner的名字, 如果再进一步使用服务器端用户访问此文件, 如果服务器端的 umask 是0022 除了root 没有一个用户能查看,修改或删除它. 这样其实带来一个好处, 只有客户端用户能访问他所创建的文件, 如果我们严格限制服务器端的 root权限, 理想状况下能很好的保护客户端用户的隐私.

另起一段, 让事情再复杂一些, 假设服务器上没有zhangsan(uid:999) 这个用户, 只有有李四lisi(uid:999) 这个用户, 那么会怎样? 此时, 张三创建的文件, 会显示 owner 是李四(lisi), 如果这个文件里面有张三的隐私的话, 那么张三的隐私有可能被泄露, 如果是钱的哈, 有可能被转走. 这很不安全,NAS为我们留下了一个巨大的安全漏洞, 也给我们提供了解决办法, 那么怎么防止这一点呢, linux 也可以做到, 这就需要研究ACL权限控制了, 这里不做展开.

以上不算最严重的情况, 毕竟服务器端, 恶意篡改的可能性相对比较小, 也容易控制. 下面这种情况就比较糟糕了, 假设现在有多个客户端可以访问共享目录, 这些客户机上分别有 李四 lisi(uid:999) 王五 wangwu(uid:999), 赵六zhaoliu(uid:999) , 那么他们都能看到彼此创建的文件, 如果是隐私或保密数据, 那将是是糟糕的不能再糟糕的一件事情. 难道隐私数据就不能放在NAS上吗? 之前说了, 这取决于管理员的配置水平, NAS权限配置可以精细到单个ip级别, 不同的ip只能访问到不同的目录, ip+uid 可以让用户彼此隔离开来, 或者引入LDAP, 单点登录, 让不同的用户拥有不同的uid也能防止重复的问题, 而且可以很好的结合LDAP身份验证功能. 但是任何事物都有两面性, 假设架设NAS的目的就是为了分享, 为了协同工作, 那么这种设置又能很容易的达到目的. 所以NAS的权限管理可以很灵活, 也可以做到很严谨, 也可能很糟糕, 取决于使用目的以及管理水平.

讲了这么多, 才讲完了no_root_squash, no_all_squash 两个选项, 是不是超级复杂? 这就完了吗? 当然还没有完, 因为权限控制问题本身就很复杂, 在任何一个系统中都是逻辑最复杂最混乱的一块. 当我们试图解决客户端uid重复的时候, 有没有发现一个新的问题, 问题一, 如果按ip+uid 唯一映射共享目录, 可以做到很好的隔离, 但是配置文件会膨胀的非常快, 会相当混乱, 维护起来会相当困难, 复杂性转移到了配置管理了, 有没有? 问题二, 如果采用LDAP, 客户端uid可以实现唯一, 但是我们知道任何客户端的东西都可能被恶意篡改, 难免有不怀好意的用户, 那么我们必须把控制权掌握在自己手中, 不给恶意使用者留下机会. 那要怎么办呢? 这里就是身份映射闪亮登场的时候了. 为什么需要身份映射.

刚刚说了, 在以隐私保护,数据安全为导向的权限设置中,最大的威胁是uid重复. 这里我们引入了LDAP, 也就引入了身份验证, 也尽量避免uid重复, 但是防止不了伪造. 我们也知道NAS 没有引入身份验证的功能, 尽量保持简便灵活. 既然没有引入身份验证, 理论上是不能很好的做到数据隔离的, 更何况我们也有数据共享的必要,协作的必要. 引入身份验证可能使得协助,共享变得困难,复杂. 既然不能保证全体用户的隔离, 我们还是能保证部分敏感用户是隔离的. 假设我们以保护张三的隐私为最高优先级, 那么王五赵六的为次优先级. 那么我们就可以把王五赵六映射为nfsnobody, 张三的映射到全服务器上唯一的一个用户上, 这样就避免了张三与其他用户uid冲突的问题, 服务器端严格限制张三对于的uid的权限, 除了root可以访问,尽量不让其他用户访问张三的隐私数据. 当然如果root用户要作恶, 技术手段是很难防止的了得, 只有通过行政手段,法律措施, 规章制度来保证.

这应该就是引入 root_squash, all_squash, anonuid, anongid的目的, 要搞懂这些选项, 先要弄懂这几个单词的含义很重要, squash 这里采用的是压扁的意思, 想象一下网络上的用户(赵钱孙李,周吴郑王) 像潮水一遍的向NAS涌来, 在进入nas服务之前, 将他们压缩,压扁成一个用户nfsnobody(nfs小人物) 当我们在服务器上安装nfs-utils的时候,默认就会创建一个nfsnobody用户, 如果我们不想使用nfsnobody, 或者一个nfsnobody根本不够用, 我们可以使用 anonuid 指定映射身份. root_squansh 表示无论那个客户端来的root压扁成nfsnobody, all_squash 表示无论哪个客户端来的普通用户压扁成服务器上的nfs小人物, 那么大人物是谁? 就是那些以真实身份访问服务器的用户, 他们的隐私应该得到更好的保护. anonuid 中的anon 就是anonym匿名或无名的缩写(a是否定前缀, nonym跟name同源, 相当于中文的无名), uid 则对于 linux uid (user id), 这样这些选项就容易理解, 不容易配错了. sync选项与权限无关,是用来控制内存数据和硬盘数据是否同步, 要深入了解这个选项, 就要进一步了解Linux 的IO模型, 网络传输协议了, 此处不做展开.

4.2.3. 配置NFS相关服务

  1. 设置开机启动

        systemctl enable rpcbind
    systemctl enable nfs
    systemctl enable nfs-lock
    systemctl enable nfs-idmap

  2. 启动服务

        systemctl start rpcbind
    systemctl start nfs
    systemctl start nfs-lock
    systemctl start nfs-idmap

4.3. 查看NAS状态

4.3.1. 查看服务端口占用，以便开着防火墙的时候设置

我们在使用rpcinfor -p 查看nfs的服务时, 会看到nfs注册了以下服务.

$ rpcinfo -p

program vers proto   port  service
100000    4   tcp    111  portmapper
100000    3   tcp    111  portmapper
100000    2   tcp    111  portmapper
100000    4   udp    111  portmapper
100000    3   udp    111  portmapper
100000    2   udp    111  portmapper
100005    1   udp  20048  mountd
100005    1   tcp  20048  mountd
100005    2   udp  20048  mountd
100005    2   tcp  20048  mountd
100005    3   udp  20048  mountd
100005    3   tcp  20048  mountd
100024    1   udp    662  status
100024    1   tcp    662  status
100003    3   tcp   2049  nfs
100003    4   tcp   2049  nfs
100227    3   tcp   2049  nfs_acl
100003    3   udp   2049  nfs
100003    4   udp   2049  nfs
100227    3   udp   2049  nfs_acl
100021    1   udp  32769  nlockmgr
100021    3   udp  32769  nlockmgr
100021    4   udp  32769  nlockmgr
100021    1   tcp  32803  nlockmgr
100021    3   tcp  32803  nlockmgr
100021    4   tcp  32803  nlockmgr

可以看到, rpcbind 监听在111端口, nfs监听在2049 端口. 目前支持的nsf协议有版本v1,2,3,4.
假设我们现在以vi编辑器打开并修改某个以nfs方式挂载至客户机的文件t的文件test.txt
客户端portmap 首先向服务器端的111端口发起请求, 询问nfs服务的端口号, 服务端portmap会反馈2049, 客户端立即通过2049端口与服务端建立链接.
建立链接后, 服务端进一步发送访问test.txt的请求, 服务段经过nfs_acl鉴权, 如果用户有权限访问, 則放行请求, 否则提示权限不足, 由于是写文件, 需要通过nlockmgr获得文件锁, 否则等待锁释放.

4.4. NAS文件名字符集问题说明

前面分析了, 客户端uid不一致可能和服务器端不一致, 会带来很多安全问题. 下面讨论一下客户端与服务器端字符集不一致可能导致的问题. 客户端的字符集可能千奇百怪, 服务器端只能设置一种字符集, 如何以不变应万变呢? 首先我们要搞清楚文件在计算机中是如何存储的, 也不用太深入, 起码要弄明白两个概念, inode, block. 我们经常会见到乱码的问题, 尤其是文件名, 当然如果内容是文本文件, 当使用文本编辑器打开的时候也会遇到乱码的问题, 如果是binary文件, 给机器读取的,到是不必太过担心. 下面我们来分析一下, 为什么会遇到乱码问题. 文件名是存储在inode中的, 二进制数据在传输的过程中, 理论上是不会改变的, 如果客户端是GBK编码的二进制信息, 服务器收到的后会原样保存, 如果客户端和服务器端字符编码不一致, 这时候服务器端可能看起来就是乱码. 这种情况下, 只是NAS 管理员看到文件名很迷糊, 客户端没影响, 这不影响客户的使用, 但是影响管理员的管理工作, 试想如果管理员要给文件移动一个位置, 面对一堆乱码, 确实是很头疼的一件事.

这里让问题再复杂一些, 假设现在有两个客户端同时能访问, 编辑同一个共享文件, 他们的编码方式还不一样, 那么甲保存的文件名, 乙看起来可能就是乱码. 乙修改后甲看起来就是乱码, 如果两个人脾气不好, 有可能打起来, 如果两人都比较温和内向, 也有可能心生怨恨. 这里个人觉得没有什么很好的办法彻底解决乱码的问题, 只有一些折中的方案, 第一点, 尽量不要使用中文命名文件, 不是万不得已尽量不要使用中文来命名文件. 第二点, 服务器端和客户断尽量使用utf8编码, 毕竟他支持的中文字符要全面, 也支持其他各国文字, 唯一的缺点是部分中文字符需要四个字节来存储, 大部分中文常用字符也需要二到三个字节来存储, 考虑到现在计算机的存储相对便宜, cpu的速度很快, 大多数情况都不饱和, 如果你的系统对存储,对性能要求不是十分的苛刻, 服务器端尽量使用utf8, 做到对尽量多的字符提供支持. 客户端如果能统一编码方式为utf8那是最好, 如果不能只能告诉客户端很抱歉, 我们只能做到这种地步了, 最多能在提供一个工具在客户端转码吧, 毕竟utf8编码还可以嗅探出编码格式, 如果是其他编码格式, 可能无能为力. 如果你有更好的解决方案, 欢迎在下方留言.

inode 存储了如下信息:

inode包含文件的元信息，具体来说有以下内容：

  • 文件的字节数
  • 文件拥有者的User ID
  • 文件的Group ID
  • 文件的读、写、执行权限
  • 文件的时间戳，共有三个：ctime指inode上一次变动的时间，mtime指文件内容上一次变动的时间，atime指文件上一次打开的时间。
  • 链接数，即有多少文件名指向这个inode
  • 文件数据block的位置

例如我们使用stat命令查看一个文件的inode信息, 我特意创建了一个中文命名的文件, 现在假设服务器上使用的是utf-8编码, 客户端是GBK编码, 那么客户端看到的文件名就可能是乱码.

[root@i-mywts1aa test]# stat 测试.txt
File: ‘测试.txt’
Size: 0 Blocks: 0 IO Block: 4096 regular empty file
Device: 25h/37d Inode: 250655 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2020-11-18 02:36:02.309190000 +0800
Modify: 2020-11-18 02:36:02.309190000 +0800
Change: 2020-11-18 02:36:02.309190000 +0800
Birth: -

5. NFS客户端安装与设置

5.1. linux客户端

  • 安装必要软件

    yum -y install nfs-utils
showmount -e 192.168.1.13   //192.168.1.13 为nfs 服务器ip

  • 临时挂载

    • 创建目录，修改权限

      # 创建挂载点:
mkdir /mnt/data
chmod 777 /mnt/data        //此处权限需要根据实际情况调整, 777 权限过于开放挂载:
mount -t nfs 192.168.1.13:/shared /mnt/data

  • 查看挂载：

    $df -h
文件系统                 容量  已用  可用 已用% 挂载点
devtmpfs                 898M     0  898M    0% /dev
tmpfs                    910M     0  910M    0% /dev/shm
tmpfs                    910M  9.6M  901M    2% /run
tmpfs                    910M     0  910M    0% /sys/fs/cgroup
/dev/mapper/centos-root   47G  8.5G   39G   18% /
/dev/sda1               1014M  150M  865M   15% /boot
tmpfs                    182M     0  182M    0% /run/user/0
192.168.1.13:/shared     27G  2.4G   25G    9% /mnt/data

  • 卸载方法

     umount /mnt/data

  • 设置开机自动挂载

    修改/etc/fstab, 添加一条
    192.168.1.13:/shared /data nfs defaults,_rnetdev 1 1
    备注：第1个1表示备份文件系统，第2个1表示从/分区的顺序开始fsck磁盘检测，0表示不检测。

    _rnetdev 表示主机无法挂载直接跳过，避免无法挂载主机无法启动

5.2. windows客户端

Windows下面默认没有mount，需要添加功能。

比如Windows 10：(备注: windows 10家庭版除外,家庭版不带nfs功能, 需要专业版或企业版 )

设置->应用->程序和功能->启用或关闭Windows功能：勾选上NFS服务

windows nfs
很多博客都讲了windows上如何挂载 但是没有讲如何取消挂载

删除可以使用图形界面取消, 也可以使用umount 命令 例如:

用法: umount [-f] <-a | drive_letters | network_mounts>

umount G:

-a 删除所有 NFS 网络装入点
-f 强制删除 NFS 网络装入点

5.3. 遇到的坑

clnt_create: RPC: Port mapper failure – Timed out

STATD_OUTGOING_PORT=2020

原因:端口被防火墙屏蔽

解决办法: 设置防火墙,接收来自nfs各端口的上行请求

6. 扩展阅读

NFS 协议 Mount 过程揭秘

7. 后记

本技术博客原创文章位于鹏叔的IT技术博客空间 - CentOS7搭建NAS文件共享存储, 要获取最近更新请访问原文.

更多技术博客请访问: 鹏叔的IT技术博客空间

8. 参考文档

CentOS7搭建NAS文件共享存储

NFS服务的用户身份映射

NAS之NFS原理

NAS的字符编码 Unicode

NAS原理简介

NFS 协议 Mount 过程揭秘

posted on 2020-11-17 02:17  eagle.supper  阅读(10227)  评论(0)  编辑  收藏  举报