我有一台装有 Centos 7 的虚拟机，我想在上面安装一些 ext4 分区。物理磁盘实际上是 vSphere 提供的硬盘。所有磁盘都位于同一个 NAS 上 - 因此三个正常工作的磁盘 (a、c、d) 与有问题的磁盘 (e、f、g) 几乎完全相同
fstab的内容：
UUID=b6ebbca4-71d0-4d2e-bc1a-e465e5190698 /boot ext4 defaults 1 2
UUID=2c3ab9f5-60a6-4a79-ada3-84737eef7748 / ext4 defaults 1 1
UUID=e130758c-5108-44de-bbd8-7e003c9072bc swap swap defaults 0 0
UUID=decbbdb6-8362-41ef-aa72-83066c172913 /home ext4 defaults 1 2
UUID=5717b613-a9f4-43c9-95d2-cfbbb891bd19 /apps_home ext4 defaults 1 2
UUID=e24df090-2dda-404c-8944-a28bd37d6c5e /apps/var/progress ext4 defaults 1 2
UUID=5f254c77-a91d-4255-8315-9325ddb7a9d8 /apps/var/standard ext4 defaults 1 2
UUID=746c70c1-002a-4249-a06f-df393a99252c /apps/var/custom ext4 defaults 1 2
lsblk -o '+UUID,FSTYPE'输出：
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT UUID FSTYPE
sda 8:0 0 50G 0 disk
├─sda1 8:1 0 1G 0 part /boot b6ebbca4-71d0-4d2e-bc1a-e465e5190698 ext4
└─sda2 8:2 0 49G 0 part / 2c3ab9f5-60a6-4a79-ada3-84737eef7748 ext4
sdb 8:16 0 40G 0 disk
└─sdb1 8:17 0 40G 0 part [SWAP] e130758c-5108-44de-bbd8-7e003c9072bc swap
sdc 8:32 0 50G 0 disk
└─sdc1 8:33 0 50G 0 part /home decbbdb6-8362-41ef-aa72-83066c172913 ext4
sdd 8:48 0 600G 0 disk
└─sdd1 8:49 0 600G 0 part /apps_home 5717b613-a9f4-43c9-95d2-cfbbb891bd19 ext4
sde 8:64 0 250G 0 disk
└─sde1 8:65 0 250G 0 part /apps/var/progress e24df090-2dda-404c-8944-a28bd37d6c5e ext4
sdf 8:80 0 1T 0 disk
└─sdf1 8:81 0 1024G 0 part /apps/var/standard 5f254c77-a91d-4255-8315-9325ddb7a9d8 ext4
sdg 8:96 0 2T 0 disk
└─sdg1 8:97 0 2T 0 part /apps/var/custom 746c70c1-002a-4249-a06f-df393a99252c ext4
sr0 11:0 1 1024M 0 rom
问题是，在重启后，fstab 不会持续挂载最后三个分区（应该分别挂载在和下/apps/var/progress /apps/var/standard）/apps/var/custom。它会不时挂载其中一个分区（挂载这三个分区中的任何一个分区完全是随机的，并且始终只挂载一个分区或不挂载任何分区）。其他分区会持续挂载，没有任何问题。
mount -a 选项没有执行任何操作，但是 $mount /dev/sde1（或 dev/sdf1 或 dev/sdg1）工作正常。同样，使用命令 $mount /apps/var/progress 进行安装也没有任何问题。
目前我只是在每次重启后使用 cron 来挂载这三个分区，但从长远来看，我想知道这种奇怪行为的根本原因。
我尝试用 /dev/sd* 名称替换 UUID，并尝试添加引号。
mount 总是显示分区已安装在正确的目录上，但是 umount 报告该分区目前尚未安装。
我注意到这三个有问题的分区之前使用的是 ext3 文件系统，后来不知怎么的被转换成了 ext4。此外，对于这三个分区，blkid 除了显示 UUID 外，还显示 PARTUUID（我认为它们之前在 centos 6 中使用过）
答案1
从评论中的讨论总结：
您的问题本质上是您在挂载点路径中使用了符号链接，而系统在启动时无法正确遵循这些符号链接，无法将结果识别为“嵌套挂载”。因此，systemd 没有按照正确的顺序挂载您的文件系统来处理这种依赖关系。
您有一个挂载点
/apps_home你有一个符号链接
/apps --> /apps_home/apps并且您还尝试在
/apps/var/progress/apps/var/custom和上安装卷/apps/var/custom
问题是，挂载点在挂载/apps/var/[custom|progress|standard]之前不存在。/apps_home
解决方案：
保留符号链接，但将文件系统挂载在符号链接目标的实际目录路径上：即将 fstab 条目转换为：
UUID=5717b613-a9f4-43c9-95d2-cfbbb891bd19 /apps_home ext4 defaults 1 2
UUID=e24df090-2dda-404c-8944-a28bd37d6c5e /apps_home/apps/var/progress ext4 defaults 1 2
UUID=5f254c77-a91d-4255-8315-9325ddb7a9d8 /apps_home/apps/var/standard ext4 defaults 1 2
UUID=746c70c1-002a-4249-a06f-df393a99252c /apps_home/apps/var/custom ext4 defaults 1 2
systemd-fstab-generato将生成所需的挂载单元文件和 systemd.mount将隐式添加正确的依赖项：
如果文件系统层次结构中一个挂载单元位于另一个挂载单元之下，则会自动创建两个单元之间的需求依赖关系和顺序依赖关系。
替代方案：从 /etc/fstab 中删除条目并创建您自己的挂载单元文件，然后手动配置要求和排序依赖项以确保/apps/var/progress
/apps/var/custom和/apps/var/custom不会在之前挂载/apps_home。
答案2
mount 总是显示分区已安装在正确的目录上，但是 umount 报告该分区目前尚未安装。
从评论中的讨论来看，我认为您的系统之所以出现这种行为，是因为/etc/mtab它是常规文件，而不是指向 的符号链接/proc/self/mount。我建议您恢复符号链接，如本文所述红帽解决方案：
在 Red Hat Enterprise Linux 7 中，
/etc/mtab不再是平面文件，而是指向/proc/self/mounts。如果某个服务出于某种原因使用sed命令访问或修改/etc/mtab，则可能会删除符号链接并创建平面文件。这反过来会导致服务器无法完全正常启动，它会进入紧急模式，df输出显示所有内容都已安装，但如果/proc/mounts检查，则只会/安装。