Centos 7-fstabは一部のパーティションをマウントしませんが、マウント/ dev / sd *はマウントします
centos 7を備えた仮想マシンがあり、そこにいくつかのext4パーティションをマウントします。物理ディスクは、実際にはvSphereが提供するハードディスクです。すべてのディスクが同じNAS-にあるため、3つの動作しているディスク（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が最後の3つのパーティション（/apps/var/progress/apps/var/standardおよび/apps/var/customの下にそれぞれマウントされることになっている）を一貫してマウントしないことです。それは時々それらの1つをマウントします（これら3つのうちのいずれかがマウントされると完全にランダムになり、マウントされるのは常に1つだけかまったくない）。他のパーティションは問題なく一貫してマウントされています。
Mount -aオプションは何もしていませんが、$ mount/dev/sde1（またはdev/sdf1またはdev/sdg1）は魅力のように機能します。同様に、コマンド$ mount/apps/var/progressを使用したマウントも問題なく機能します。
今のところ、リブートのたびにcronを使用してこれらの3つのパーティションをマウントしていますが、長期的には、この奇妙な動作の根本的な原因を知りたいのです。
UUIDを/ dev/sd *名に置き換えてみて、引用符を付けてみました。
mountは常にパーティションが正しいカタログにマウントされていることを示しますが、umountはパーティションが現在マウントされていないことを報告します。
問題のある3つのパーティションには以前にext3ファイルシステムがあり、何らかの形でext4に変換されていることに気付きました。また、これらの3つのパーティションでは、blkidはUUIDに加えてPARTUUIDを表示します（以前はcentos 6で使用されていたと思います）
コメントでの議論からの要約：
問題は本質的に、マウントポイントパスでシンボリックリンクを使用していて、ブート時にシステムがそれらを正しくたどることができず、結果が「ネストされたマウント」として認識されなかったことです。そのため、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。
mountは常にパーティションが正しいカタログにマウントされていることを示しますが、umountは現在パーティションがマウントされていないことを報告します。
コメントでの議論から、/etc/mtabは/proc/self/mountをターゲットとするシンボリックリンクではなく通常のファイルであるため、システムはその動作を示していると思います。これに記載されているように、シンボリックリンクを復元することをお勧めします Red Hatソリューション ：
Red Hat Enterprise Linux 7では、
/etc/mtabはフラットファイルではなく、/proc/self/mountsへのシンボリックリンクになっています。何らかの理由でサービスがsedコマンドを使用して/etc/mtabにアクセスまたは変更する場合、シンボリックリンクが削除され、フラットファイルが作成される可能性があります。これにより、サーバーは正常に完全に起動せず、緊急モードになり、df出力にはマウントされたすべてが表示されますが、/proc/mountsがチェックされている場合、/のみがマウントされます。