企业官网建设流程全解析

1. NAS这块内容在RH134里到底考什么——协议选型与适用场景的底层逻辑

很多人备考RH134的时候，拿到目录看到"访问网络附加存储"这一章，第一反应是：这不就是mount一个共享目录嘛，有什么好学的？这个想法我见过太多次了，结果就是在模拟环境里一挂载就懵了——NFS和SMB的挂载命令看着差不多，报错信息却完全是两套逻辑，showmount、smbclient、mount -t各管一摊，真正遇到权限和版本问题的时候，如果不懂协议层面的区别，排查起来会非常吃力。

先说清楚一个概念：RH134里的"网络附加存储"，本质上不是让你去搭存储服务器，而是让你掌握客户端视角的访问能力——也就是在一台Linux主机上，通过标准协议把远程目录挂载到本地，像使用本地磁盘一样读写数据。这一章在RHCSA考试里占比不算特别大，但几乎是必考的，因为它是后续RHCE自动化、存储管理、日志收集这些场景的公共基础。

NFS和SMB是两条完全不同的技术路线，我这里先用一张表把核心差异摆出来，后面所有实操环节都会围绕这张表展开。

为什么RH134要把这两个协议放在同一章里讲？因为在真实服务器环境里，一个运维工程师要面对的NAS设备既有Linux NFS服务器，也有Windows文件服务器，甚至还有商业NAS设备（比如某品牌的网络存储）同时支持这两种协议。你必须有"看协议选命令"的意识——不是所有网络存储都用同一条命令去访问，这在面试和实操里都是基本功。

另外一个需要提前建立的认知是"挂载"和"访问"的区别。RH134这一章不只讲mount命令本身，还包括autofs按需挂载、开机自动挂载、多用户会话挂载这些机制。这些内容在工作里非常实用，因为生产环境不可能让你每次手动敲mount，绝大多数情况是要做到"开机即有、用时即挂、权限可控"。这篇文章我会按照自己备考和实际维护服务器时的思路，把这一章的完整链条从原理到命令再到避坑点全部过一遍。

2. NFS挂载实操：从mount命令到fstab的完整链路

2.1 环境准备里最容易被忽视的软件包

NFS客户端听起来只要mount就行，其实不然。在Red Hat系系统上，访问NFS共享至少需要安装nfs-utils这个包，它提供了mount.nfs、showmount等一系列工具。我在模拟环境里见过A同学图省事，直接mount -t nfs，结果报mount: unknown filesystem type 'nfs'，这个报错的本质就是内核找不到对应的文件系统模块和辅助工具。

安装命令很简单：

sudo dnf install -y nfs-utils

装完之后建议顺手验证一下版本信息，方便后面判断协议版本：

rpcinfo -p 服务器IP | grep nfs

rpcinfo可以反查远程服务器上注册的RPC服务，这个命令在排错时非常有用。如果服务器同时启用了NFSv3和NFSv4，你会看到不同版本的注册信息。这里有个很多人踩过的坑：NFSv3依赖rpcbind和portmap做端口动态映射，NFSv4则固定走TCP端口2049。所以如果你遇到"服务器防火墙规则很宽松，但NFS就是挂不上"的情况，多半是rpcbind相关的端口没放行，或者服务器只开了2049但客户端强制协商到了NFSv3。

2.2 手工挂载的最佳实践：先查再挂

拿到一个NFS共享地址，不要急着mount。先查后挂是职业习惯。查询命令是showmount：

showmount -e 192.168.1.100

比如输出：

Export list for 192.168.1.100: /data/share1 192.168.1.0/24 /data/backup *

这表示服务器导出了两个目录，share1只允许192.168.1.0/24网段访问，backup对所有主机开放。注意，*不代表谁都能读写，它只是导出规则里的主机匹配，最终还叠加了Unix文件系统权限和NFS的squash配置。

挂载命令的标准形态是：

sudo mount -t nfs 192.168.1.100:/data/share1 /mnt/share1

我建议你写命令时把版本和传输模式显式写出来，避免内核去猜：

sudo mount -t nfs -o rw,vers=4.2,hard,timeo=600,retrans=2 192.168.1.100:/data/share1 /mnt/share1

这里面的参数含义值得逐一说一下：

• vers=4.2：指定NFS协议版本。NFSv4.2是RHEL 8/9时代比较稳妥的选择，支持服务端拷贝等高级特性；如果服务器比较老旧，可以退到vers=4.1或vers=3。
• hard：当NFS服务器无响应时，客户端一直阻塞重试，不报错。生产环境建议用hard而不是soft，因为soft模式超时后可能返回错误的IO结果，严重时导致数据损坏。这是RH134里反复强调的一个点，考试选择题喜欢考。
• timeo=600：超时时间，单位是0.1秒，600即60秒。网络抖动频繁的环境可以加大。
• retrans=2：重传次数。配合hard模式，NFS会持续重试直到服务器恢复。

挂载之后用df -h或mount | grep nfs确认。想查看某目录实际所在文件系统的挂载参数，用findmnt更清晰：

findmnt /mnt/share1

2.3 权限问题：root被压缩、普通用户被拒绝

权限这一块是NFS最容易让新手困惑的地方。NFS服务器默认开启root_squash，意思是远程root用户映射为匿名用户（通常nobody），这是出于安全考虑——不然任何一个客户端root都能以服务器root身份写文件，风险非常大。如果你挂载后发现客户端用root写入的文件在服务器上属主是nobody，不要惊讶，这是正常行为。

反过来，普通用户被拒绝访问，一般是两个原因。第一，服务器的导出选项限制了客户端的访问网段，也就是exports文件里只允许某个IP池访问；第二，NFS共享目录的文件权限（如目录属主、属组、权限位）不允许远程用户对应uid/gid访问。第三点很隐蔽：NFS默认按数字UID/GID匹配，而不是按用户名匹配。假如客户机上有个用户uid是1005，服务器上同一个uid对应的可能是另一个用户，权限判断就会出问题。

我在实际排障时遇到过这么个案例：某公司两台Linux服务器通过NFS共享了一个部署目录，开发在客户端用root拷贝文件，到了服务器端发现属主全变成了nobody，然后其他服务就读取不了了。后来方案调整成在exports里加anonuid和anongid参数，把匿名用户映射到某个固定服务账号，才解决掉。RH134讲义里会提到这两个参数，考试不一定考，但工作中非常实用：

/data/deploy 192.168.1.0/24(rw,anonuid=1001,anongid=1001,no_root_squash)

no_root_squash这个选项要慎用，它的意思是保留客户端root的权限，不做压缩映射。只有你明确知道自己在做什么、且网络环境可信时，才建议使用。

2.4 开机自动挂载：fstab的坑与正确写法

考试和工作里都绕不开/etc/fstab。NFS条目写法和本地文件系统有点区别，一个规范的例子是：

192.168.1.100:/data/share1 /mnt/share1 nfs rw,hard,vers=4.2,timeo=600 0 0

最后两列分别是dump备份标志和fsck检查顺序。NFS共享不需要dump，设为0；fsck也不需要做，设为0。很多人会在这里纠结"为什么不是1 2"，本地根分区才用1，非根本地分区用2，网络文件系统全部用0，这是原则。

fstab里还有一个非常隐蔽的坑：如果你在fstab里写了NFS条目，但开机时网络还没就绪，系统可能卡在挂载环节，甚至进入紧急模式。Red Hat的解决方案是在挂载选项中加_netdev：

192.168.1.100:/data/share1 /mnt/share1 nfs rw,hard,vers=4.2,_netdev 0 0

_netdev告诉systemd：这个挂载点依赖网络，等网络准备好之后再执行挂载，不要阻塞开机流程。这个选项不只在NFS里用，SMB挂载同样适用。

更灵活的做法是配合systemd的automount机制，也就是让挂载行为按需触发。在fstab里加x-systemd.automount选项：

192.168.1.100:/data/share1 /mnt/share1 nfs rw,hard,vers=4.2,x-systemd.automount 0 0

这样系统启动时只建立挂载单元，不真正挂载，直到有进程访问/mnt/share1时才触发实际挂载。好处有两个：一是减少开机消耗，二是避免网络延迟导致开机卡死。RH134的第9章虽然没有展开讲systemd automount，但如果你了解这个概念，考试里涉及fstab故障排错时会比其他人多一层判断维度。

3. SMB/CIFS客户端配置：从手工挂载到多用户会话

3.1 为什么Linux要访问SMB共享

很多刚接触Linux的人会有个思维定式：Windows共享是Windows的事，跟Linux有什么关系？但真实企业环境里，往往存在大量Windows文件服务器，而Web服务器、日志分析服务器、备份服务器却是Linux的。比如某公司有个业务系统，应用跑在Linux上，但财务导出的报表放在Windows Server的共享文件夹里，Linux应用需要定期拉取。这时候Linux就要以SMB客户端身份去访问Windows共享。

SMB在Linux下的挂载工具是cifs-utils：

sudo dnf install -y cifs-utils

这里要更正一个概念：大家习惯说"CIFS"，其实CIFS是SMB协议的一个早期方言版本，现代内核里cifs文件系统驱动已经实现了SMB2和SMB3的支持。所以命令还是mount -t cifs，但协议版本已经远超当年的CIFS。

3.2 手工挂载SMB共享的标准流程

假设Windows服务器地址是192.168.1.50，共享名为share2，挂载命令可以这么写：

sudo mkdir -p /mnt/share2 sudo mount -t cifs //192.168.1.50/share2 /mnt/share2 -o username=yourname,domain=corp.example.com

执行后系统会提示输入密码，这是相对安全的交互式方式。如果要在脚本或fstab里使用，就不适合交互输入，需要用到credentials文件：

sudo mkdir -p /etc/smbcredentials sudo vi /etc/smbcredentials/share2.cred

文件内容：

username=yourname password=yourpassword domain=corp.example.com

然后设置权限，这个文件只有root能读：

sudo chmod 600 /etc/smbcredentials/share2.cred

挂载命令变成：

sudo mount -t cifs //192.168.1.50/share2 /mnt/share2 -o credentials=/etc/smbcredentials/share2.cred,vers=3.0

这里我用vers=3.0显式指定协议版本。为什么？因为Windows Server 2016以上的默认策略往往禁用SMB1，如果客户端不指定版本，某些旧内核会尝试SMB1然后握手失败。指定vers=3.0是一个比较稳妥的折中，新版Windows和主流NAS设备都支持SMB3.0。当然如果对方是更老的系统，可能要回退到vers=2.0甚至vers=1.0，但SMB1我建议能不用就不用，安全性太差。

挂载成功后用df -h验证。想看到更详细的挂载选项，可以用findmnt -M /mnt/share2，输出里会列出uid、gid、file_mode等参数。

3.3 多用户挂载：一个挂载点，多人不同权限

手工挂载和fstab挂载只能使用一个固定的凭据，这在单机场景没问题。但如果是多用户Linux服务器要访问同一个SMB共享，每个人用自己的域账号访问自己的目录，怎么处理？RH134里专门有这一节：多用户SMB挂载。

核心思路是：挂载时使用一个特权凭据完成挂载，但通过multiuser选项启用运行时切换身份；之后每个用户使用cifscreds命令提交自己的凭据，内核再按照访问者的身份进行权限判定。

挂载命令：

sudo mount -t cifs //192.168.1.50/share2 /mnt/share2 -o username=adminuser,multiuser,sec=ntlmssp,credentials=/etc/smbcredentials/share2.cred

然后普通用户登录系统后执行：

cifscreds add -u alice 192.168.1.50

系统提示输入alice的密码。之后alice访问/mnt/share2时，内核会用alice的凭据向服务器请求访问权限。这个机制在不配置Kerberos的环境下非常实用，避免了给所有用户配置credentials文件的麻烦。

关于sec参数，常见的取值有ntlmssp、krb5、ntlmv2等。现代Windows环境推荐ntlmssp或krb5。如果你在一个纯Samba搭建的Linux文件服务器上做SMB共享，ntlmssp通常没任何问题。

不过multiuser在实际使用中有个体验上的问题：用户第一次访问挂载目录时，如果凭据还没有通过cifscreds提交，访问会被拒绝，提示Permission denied。这不是挂载失败，而是身份切换还没完成。我建议在测试环境里故意用未提交凭据的用户去ls一下目录，熟悉这个报错的"长相"，免得误判。

另外注意，fstab里写多用户SMB挂载时，credentials文件路径和multiuser选项都要写全：

//192.168.1.50/share2 /mnt/share2 cifs credentials=/etc/smbcredentials/share2.cred,multiuser,sec=ntlmssp,uid=root,gid=root,_netdev 0 0

这里uid和gid指定的是挂载点根目录显示的属主，不是访问者的身份。刚开始学这个的人容易混淆，记住一句话：挂载立场的身份和访问者的身份是两回事。

3.4 Windows共享看不到文件？多半是目录名大小写问题

SMB共享的目录挂载到Linux后，偶尔会出现"明明共享里有个文件夹叫Data，但ls看不到"或者"看到一堆乱码"的情况。两种原因最常见：一是服务器端启用了基于Access-Based Enumeration的隐藏访问控制，客户端无权限的目录直接不显示，这不是Linux的问题；二是字符编码不一致，Windows共享目录名如果是GBK编码，而Linux挂载后按UTF-8解析，文件名就会变成乱码。

解决办法是在挂载选项里加iocharset=utf8或codepage=cp936，具体取决于Windows服务器的语言区域。实际工作中我更建议先确认服务器端命名规范——尽量让Windows共享下的目录和文件名使用通用ASCII字符，可以省掉大量编码麻烦。RH134不会考这么细的编码问题，但面试和实操里 это 高频话题，写出来给大家做个参考。

4. autofs按需挂载：让共享存储跟着访问需求走

4.1 autofs解决的痛点是什么

到这里为止，所有挂载都是"立即生效、持续挂载"。如果一台服务器需要访问几十个共享目录，每个目录都开机挂载，先不说启动时间，单是某个存储服务器临时故障导致的挂载失败，就可能让整台机器进入紧急模式。autofs就是来解决这个问题的：它作为一种按需挂载机制，平时不占挂载点，当你访问特定路径时，由autofs服务动态完成挂载，空闲一段时间后自动卸载。

Red Hat系的autofs安装方式：

sudo dnf install -y autofs sudo systemctl enable --now autofs

autofs的架构是一个主映射文件加多个映射文件。主映射文件默认是/etc/auto.master，它定义了"哪些路径由autofs接管，对应的映射文件是什么"。

4.2 主映射与直接映射配置

举例，我希望访问/mnt/nfs下的子目录时自动挂载对应的NFS共享。先创建映射文件/etc/auto.nfs：

share1 -rw,hard,vers=4.2 192.168.1.100:/data/share1 share2 -rw,hard,vers=4.2 192.168.1.100:/data/share2

然后编辑/etc/auto.master添加：

/mnt/nfs /etc/auto.nfs --timeout=60

--timeout=60表示空闲60秒后自动卸载。

重启autofs：

sudo systemctl restart autofs

之后当你执行ls /mnt/nfs/share1时，autofs捕获访问请求，读取/etc/auto.nfs，挂载NFS共享到/mnt/nfs/share1。注意，/mnt/nfs这个父目录在系统启动后不一定存在，autofs会自动创建，这一点和普通挂载完全不同。

直接映射和间接映射的区别在于：间接映射通过"父目录+映射键"组合成挂载点，比如上面的例子；直接映射则直接在映射文件里写完整的挂载路径，用于那些挂载点本身不规律、无法归到单一父目录下的场景。直接映射的写法是在map文件里以/-开头，RH134对直接映射的要求是理解概念、会看配置，实际写起来的频率低于间接映射。

4.3 autofs与SMB的结合

autofs不只服务于NFS，SMB共享同样可以按需挂载。映射文件写法：

documents -fstype=cifs,credentials=/etc/smbcredentials/share2.cred ://192.168.1.50/share2

这里注意-fstype=cifs的写法，它告诉autofs当前条目的文件系统类型不是NFS而是CIFS。挂载参数的写法和mount命令基本一致，只是用逗号分隔放在-fstype后面。冒号用来分隔选项部分和源路径部分，这是一个比较特殊且容易写错的语法。

我见过不少人在autofs映射文件里漏掉冒号，然后得到各种匪夷所思的错误。这里强调一下：映射格式的完整结构是"键 选项 源"，选项和源之间一定有空格，源里的冒号是SMB/网络路径的一部分，不能省。

4.4 为什么生产环境更倾向autofs而非fstab

作为运维，我的习惯性建议是：如果一台机器要长期访问的共享数量少于三个且网络稳定，fstab直挂加_netdev完全够用；如果共享多、或者部分共享不是高频访问，autofs的优势非常明显。

第一，autofs减少了静态挂载点数量，systemctl daemon-reload后即使某个挂载失败，不会影响开机引导。第二，按需挂载意味着存储服务器离线时，客户端只是访问路径会卡一下或提示找不到，而不是整机启动流程卡死。第三，autofs的--timeout机制自带断连后回收，不用手动umount。

RH134考试大纲里autofs的比重不低，经常以"给你一个共享目录，要求配置autofs按需挂载，验证访问"这样的任务形式出现。练习的时候建议自己从零走一遍：装包、写map、改master、重启、验证、改timeout验证自动卸载。这一遍走下来，比背十条命令都管用。

5. 验证、排错与RHCSA实战视角的拾遗

5.1 挂载验证的正确顺序

每次配置完挂载，不要只看mount命令有没有输出。一套完整的验证顺序应该包含：

1. 查看挂载点实际文件系统类型和选项，用findmnt。
2. 测试读写权限，创建临时文件再删除。

echo "test" > /mnt/share1/test.txt cat /mnt/share1/test.txt rm /mnt/share1/test.txt

3. 如果是SMB，用smbclient先做一个协议层的探活：

smbclient //192.168.1.50/share2 -U yourname -m SMB3

smbclient能直接列出共享根目录的内容，同时验证认证、协议版本和网络连通性。这一步能帮你快速区分"网络问题""协议问题""权限问题"三个层次。

4. 重启系统或重启相关服务验证开机挂载是否正常。这个步骤最花时间，但最能暴露fstab和systemd之间的问题，值得做一次。

5.2 NFS挂载失败的完整排查链路

这里我把常见的NFS挂载失败场景和排查顺序串成一条链路，照着走能帮你避开很多无效操作。

第一层，网络连通性。ping服务器IP，再rpcinfo -p 服务器IP确认NFS服务进程是否在监听的端口上。如果rpcinfo超时，多半是防火墙阻断了111端口。

第二层，导出规则验证。showmount -e 服务器IP，确认目标共享在导出列表里，并且你客户端的IP在允许网段内。如果报Export list is available but not mounted，先从导出规则入手。

第三层，协议版本协商。尝试显式指定版本挂载，比如-o vers=3和-o vers=4.2分别试一次，观察报错差异。如果vers=4.2不行但vers=3可以，说明服务器端NFSv4配置有问题。

第四层，权限和Squash问题。挂载成功但读不了文件，查看服务器端共享目录的属性，用ls -ld /data/share1确认目录属主和权限；再看/etc/exports里的root_squash、anonuid等选项。

第五层，本地挂载点问题。挂载点目录是root拥有且权限至少755，如果不是，普通用户访问会有权限问题。有时候挂载点本身被其他文件占用，挂载会覆盖掉原内容但原内容还藏在下面，这种情况用findmnt也能看出来。

5.3 关于RHCSA考试的几个实战观察

说回RH134第9章在考试里的实际表现。RHCSA环境通常是上机实操，给你一个题目描述，要求完成配置并验证。我的经验是：审题时一定要辨认协议类型，题目里出现"NFS"或"export"字样就走NFS流程，出现"Windows共享""SMB"或"credentials"字样就走SMB流程，不要混用。

另外，Red Hat考试系统默认安装了大部分所需软件包，但autofs可能不在其中。如果题目要求用autofs，你需要自行安装并enable服务，这是完整任务的一部分。做题的时候养成习惯，凡是涉及服务配置，一律systemctl enable --now设置开机自启，避免重启扣分。

还有一个小细节：考试环境里的服务器IP和共享路径不要看错。我在模拟测试中见过B同学把IP里的1.100看成1.10，导致整整十五分钟在排查一个不存在的网络问题。配置存储类题目时，建议先在题目终端里ping一下目标服务器，确认连通后把IP抄到笔记本上，再开始写命令。

5.4 日常维护里值得养成的三个习惯

最后一个部分，分享几个和网络存储打交道时我个人觉得非常有用的习惯，不算考试内容，但长期受益。

第一个习惯是统一挂载目录的命名规范。比如NFS共享统一挂到/mnt/nfs/下，SMB挂到/mnt/smb/下，目录名用共享名或业务名，不要用IP。这样脚本和服务配置里的路径容易阅读，排查时也能一眼看出哪条路径对应什么协议。

第二个习惯是给所有自动挂载相关的服务设置监控。不管用fstab加_netdev还是autofs，都应该通过systemctl list-units | grep mount或监控系统的挂载点状态，定期确认远程存储是否在线。存储服务器出问题时，客户端往往不会立刻报错，而是在写入时才超时，这时候没有监控就只能等用户投诉。

第三个习惯是定期测试备份恢复路径。网络存储上的数据，权限模型和本地盘不一样的，NFS的squash规则和SMB的ACL都可能让你在恢复备份时遇到属主错乱。建议每隔一段时间就从客户端真实写一个文件到共享目录，再从服务器侧确认属主和权限，模拟一次完整的数据往返，确保权限模型没有被意外改动。

RH134第9章的内容看起来零碎，但把NFS、SMB、autofs这三条线串起来后，会发现它们都指向同一个能力：让Linux主机在异构存储环境中稳定、安全、自动地获取数据。这个能力在RHCSA里是考点，在实际工作中就是日常。考试前最后一天，建议你关掉文档，手动从零配置一次NFS挂载、一次SMB挂载、一次autofs，每个过程都做读写验证。能流畅走完这三遍，这一章就算真正过关了。