一块新硬盘为何看得见却用不了？Linux 手动挂载与开机自动挂载实战教程

一台 Linux 服务器刚完成交付，系统盘只有 100GB，另外配置了一块 500GB 数据盘。登录服务器后执行 df -h，却只能看到系统盘，500GB 硬盘仿佛并不存在。

但在服务器管理后台中，这块硬盘明明已经成功添加。

这种情况通常不是硬盘故障，而是因为 Linux 已经识别到磁盘设备，但磁盘尚未完成分区、格式化和挂载。下面以一块新增加的 500GB 磁盘为案例，完整演示如何让它从“系统可识别”变成“业务可使用”，并设置为服务器重启后自动挂载。

本文所说的“自动挂载”，是通过 /etc/fstab 配置新磁盘开机自动挂载，并不是重新挂载当前正在运行的 Linux 根系统盘。

场景：服务器有两块磁盘，为什么 df -h 只显示一块？

先查看当前已经挂载的文件系统：

df -hT

假设输出中只有系统根分区：

Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/vda1      ext4   99G   12G   82G  13% /

从这里看，服务器似乎只有一块 100GB 磁盘。

但 df 只显示已经挂载的文件系统，并不能用来判断服务器到底有多少块物理磁盘。此时应继续执行：

lsblk -o NAME,SIZE,FSTYPE,TYPE,MOUNTPOINTS,UUID

可能看到如下结果：

NAME   SIZE FSTYPE TYPE MOUNTPOINTS
vda    100G        disk
└─vda1 100G ext4   part /
vdb    500G        disk

这说明 Linux 已经识别到 /dev/vdb，只是它目前没有分区、没有文件系统，也没有挂载目录。

还可以使用下面的命令进一步确认：

fdisk -l

在云服务器、独立服务器和虚拟化环境中，新增磁盘的名称并不完全相同，常见情况包括：

/dev/vdb
/dev/sdb
/dev/xvdb
/dev/nvme1n1

不要直接照抄设备名称，应以当前服务器的 lsblk 结果为准。

先别急着格式化：确认这是不是一块真正的空盘

看到一块没有挂载的磁盘，不代表它一定没有数据。服务器迁移、磁盘重新接入或者系统重装后，原有数据盘也可能处于未挂载状态。

可以先执行：

lsblk -f

再检查磁盘和分区信息：

blkid

如果 /dev/vdb 或 /dev/vdb1 已经显示 ext4、xfs 等文件系统类型，说明磁盘可能已经保存过数据。这种情况下不应执行 mkfs，而应先尝试只读挂载或检查原有文件系统。

还可以执行：

file -s /dev/vdb

如果结果只是：

/dev/vdb: data

并且确认这是一块刚添加的新硬盘，才可以继续创建分区。

给 500GB 新磁盘建立 GPT 分区

本案例使用 GPT 分区表。GPT 不仅适合大于 2TB 的硬盘，也适合当前大多数新服务器。

首先创建 GPT 分区表：

parted /dev/vdb --script mklabel gpt

然后创建一个占满整块硬盘的主分区：

parted /dev/vdb --script mkpart primary ext4 0% 100%

让系统重新读取分区表：

partprobe /dev/vdb

再次查看：

lsblk

此时应该可以看到新分区：

NAME   SIZE TYPE MOUNTPOINTS
vda    100G disk
└─vda1 100G part /
vdb    500G disk
└─vdb1 500G part

如果磁盘名称是 NVMe 类型，例如 /dev/nvme1n1，对应的第一个分区通常是：

/dev/nvme1n1p1

而不是 /dev/nvme1n11。

ext4 还是 XFS？根据用途选择文件系统

分区建立后，下一步是创建文件系统。

如果服务器使用 Ubuntu、Debian，或者希望获得较好的通用性，可以选择 ext4：

mkfs.ext4 -F /dev/vdb1

如果服务器使用 Rocky Linux、AlmaLinux、CentOS，或者磁盘主要存放较大的业务文件，也可以使用 XFS：

mkfs.xfs -f /dev/vdb1

需要特别注意，mkfs 会创建新的文件系统，同时清除该分区原有的数据结构。设备名称一旦写错，可能直接格式化系统盘或者其他业务磁盘。

执行之前建议再次确认：

lsblk

本案例继续使用 ext4 文件系统。

让磁盘先临时挂载到 /data

Linux 中的磁盘不能直接以盘符形式使用，需要挂载到一个目录。

创建数据目录：

mkdir -p /data

将新分区挂载到该目录：

mount /dev/vdb1 /data

检查挂载结果：

df -hT /data

正常情况下会看到：

Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/vdb1      ext4  492G   28K  467G   1% /data

还可以使用 findmnt 查看实际挂载关系：

findmnt /data

为了确认目录可写，可以创建一个测试文件：

touch /data/mount-test.txt
ls -l /data/mount-test.txt

测试完成后删除：

rm -f /data/mount-test.txt

到这里，磁盘已经可以正常使用，但这仍然只是一次临时挂载。服务器重启后，mount /dev/vdb1 /data 的挂载关系不会自动恢复。

为什么自动挂载不建议直接写 /dev/vdb1？

最简单的自动挂载配置是将下面一行写入 /etc/fstab：

/dev/vdb1 /data ext4 defaults 0 2

这种写法虽然可以使用，但不够稳妥。

在部分云服务器、虚拟化环境或调整磁盘顺序后，原来的 /dev/vdb 可能变成 /dev/vdc。设备名称发生变化后，系统就无法按照原来的路径找到磁盘。

UUID 是文件系统的唯一标识，通常不会因为磁盘识别顺序改变而变化。因此，生产环境更适合使用 UUID 配置自动挂载。

查询新分区的 UUID：

blkid /dev/vdb1

输出示例：

/dev/vdb1: UUID="8b64b56c-7c80-4f5f-90ba-19e553c06db9" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="87ffb8d2-01"

需要使用的是 UUID，而不是 PARTUUID。

修改 fstab 前，先留下一个可恢复的副本

/etc/fstab 会影响 Linux 启动过程。配置错误时，轻则数据盘无法自动挂载，重则服务器进入紧急模式。

先备份原文件：

cp -a /etc/fstab /etc/fstab.bak.$(date +%F-%H%M%S)

然后编辑：

vi /etc/fstab

在文件末尾添加：

UUID=8b64b56c-7c80-4f5f-90ba-19e553c06db9 /data ext4 defaults,nofail 0 2

这一行可以拆解为六个部分：

UUID=磁盘UUID  挂载目录  文件系统  挂载参数  dump参数  fsck顺序

其中：

• UUID=...：指定要挂载的文件系统。

• /data：磁盘对应的挂载目录。

• ext4：文件系统类型，必须与实际格式一致。

• defaults：使用常规读写、自动挂载等默认参数。

• nofail：即使数据盘暂时不可用，也尽量允许系统继续启动。

• 0：通常表示不使用 dump 备份。

• 2：表示在根分区检查完成后，再检查该数据分区。

如果使用的是 XFS，配置中的文件系统类型应改为：

UUID=对应UUID /data xfs defaults,nofail 0 0

XFS 一般将最后一项设置为 0，不通过传统 fsck 流程检查。

对于系统启动必须依赖的关键业务盘，不应不加判断地使用 nofail。因为它可能让系统在磁盘挂载失败后继续运行，最终导致程序把文件写入系统盘上的空 /data 目录，造成系统盘容量被迅速占满。

不要直接重启，先在当前系统验证 fstab

很多服务器并不是因为磁盘本身有问题而无法启动，而是管理员修改 /etc/fstab 后没有验证，直接执行了重启。

保存配置后，先运行：

systemctl daemon-reload

然后检查 fstab 的语法和挂载配置：

findmnt --verify --verbose

如果没有发现错误，再执行：

mount -a

mount -a 会尝试挂载 /etc/fstab 中尚未挂载的文件系统。如果命令没有报错，说明配置基本有效。

由于本案例中的 /data 已经手动挂载，mount -a 可能不会重新测试这一挂载项。若服务器处于维护窗口，并且 /data 没有程序占用，可以进一步执行：

umount /data
mount -a

再次检查：

findmnt /data
df -hT /data

确认 /data 已经根据 /etc/fstab 自动挂载后，再考虑重启服务器：

reboot

服务器重新连接后执行：

findmnt /data

只要仍能看到 /data 对应的磁盘和文件系统，就说明自动挂载已经生效。

磁盘挂载成功了，程序却提示没有权限

磁盘正常挂载后，默认目录通常属于 root 用户：

ls -ld /data

可能显示：

drwxr-xr-x 3 root root 4096 Jun 24 10:20 /data

如果网站、数据库或容器程序不是以 root 身份运行，就可能无法写入。

例如，某个业务程序使用 www-data 用户，可以根据实际目录用途调整所有者：

chown -R www-data:www-data /data

如果只是希望创建一个独立的网站目录，更推荐只修改业务子目录，而不是直接开放整块磁盘：

mkdir -p /data/www
chown -R www-data:www-data /data/www
chmod 750 /data/www

不建议为了省事直接执行：

chmod -R 777 /data

这种做法会给所有本地用户开放读写执行权限，可能扩大网站程序漏洞、恶意脚本或错误操作造成的影响。

一次真实的 fstab 故障：UUID 只少了一个字符

某台服务器完成磁盘挂载后，管理员手动复制 UUID 时漏掉了最后一个字符，并直接重启了系统。

启动时，Linux 无法找到对应文件系统，最终进入 emergency mode。通过远程控制台登录后，系统提示某个挂载单元启动失败。

处理时先将根文件系统切换为可写：

mount -o remount,rw /

然后编辑：

vi /etc/fstab

将错误挂载项临时注释：

# UUID=错误的UUID /data ext4 defaults,nofail 0 2

或者将其改为正确 UUID，再执行：

systemctl daemon-reload
mount -a

确认不再报错后重启系统。

这个案例说明，自动挂载真正危险的环节通常不是 mount 命令，而是把未经验证的配置写入启动流程。

已经有文件系统的旧数据盘应该怎样挂载？

如果 lsblk -f 显示 /dev/vdb1 已经存在 ext4 或 XFS 文件系统，且磁盘内保存着旧数据，就不需要重新分区和格式化。

可以先建立临时目录：

mkdir -p /mnt/recovery

使用只读方式挂载 ext4：

mount -o ro /dev/vdb1 /mnt/recovery

如果是 XFS，并且磁盘来自其他服务器，可能因 UUID 冲突而无法挂载，可以在确认场景后尝试：

mount -o ro,nouuid /dev/vdb1 /mnt/recovery

检查目录内容：

ls -lah /mnt/recovery

确认数据完整、文件系统类型正确后，再决定正式挂载目录和 /etc/fstab 配置。对于来源不明或者曾出现掉盘、断电的磁盘，应先完成数据备份和文件系统检查，不要一上来就执行带 -f 参数的格式化命令。

服务器增加磁盘后，最稳妥的操作顺序始终是：先识别设备，再确认是否存在旧数据，然后分区、格式化、临时挂载、验证读写，最后才配置开机自动挂载。尤其是在远程服务器上修改 /etc/fstab 时，应确保服务器管理平台提供 VNC、KVM 或救援模式，否则一个字符的配置错误，也可能让原本正常运行的服务器暂时失去远程连接。