ubuntuでRAID5のアレイが起動時にマウントされない。起動後に手動でsudo mount -aならマウントされる。原因はなんだろう。

kaizawaAIとの会話

場合、主な原因は「アレイの準備が整う前にシステムがマウントを試みている（タイミングの問題）」か、「初期RAMディスク（initramfs）内のRAID設定が古い」ことのいずれかです。 

以下の手順で修正を試みてください。

1. RAID設定情報の更新と反映

RAIDの構成情報（UUIDなど）を最新の状態にして、OS起動の初期段階で読み込めるようにします。 

  1. 現在のRAID構成情報を設定ファイルに書き出す:bash# 既存の設定をバックアップ sudo cp /etc/mdadm/mdadm.conf /etc/mdadm/mdadm.conf.bak # 現在の状態をスキャンして反映 sudo mdadm --detail --scan | sudo tee /etc/mdadm/mdadm.conf
  2. initramfsを更新する:
    OS起動時にRAIDを認識させるため、この手順が最も重要です。bashsudo update-initramfs -u

2. /etc/fstab のマウントオプション調整 

RAIDデバイスの準備が遅れる場合に備え、マウントオプションに defaults だけでなく、準備を待つための設定を追加します。 

  • 推奨設定例:
    /etc/fstab 内の対象行を以下のように書き換えます（UUIDは blkid コマンドで確認してください）。textUUID=あなたのRAIDアレイUUID /mnt/mountpoint ext4 defaults,nofail,x-systemd.device-timeout=30 0 2
    • nofail: デバイスが見つからなくても起動を止めないようにします。
    • x-systemd.device-timeout=30: デバイスが現れるのを最大30秒待ちます。 

3. デバイス名の不一致の確認

起動時にRAIDアレイが /dev/md0 ではなく、/dev/md127 など別の名前で認識されている場合があります。 

  • 対策: /etc/fstab でのマウント指定を /dev/md0 のようなデバイス名ではなく、必ず UUID を使用するようにしてください。UUIDは以下のコマンドで取得できます。bashsudo blkid /dev/md0 # または現在のRAIDデバイス名

これらの設定を行った後、再起動して自動マウントされるか確認してください。

現在の /etc/fstab の設定内容や、起動直後の cat /proc/mdstat の結果を教えていただければ、より具体的な診断が可能です。

UUID=c2bc4e5e-895c-45ea-b798-99e6fcc97b05 /mnt/nas10tb ext4 defaults 0 1Personalities : [raid6] [raid5] [raid4] [raid0] [raid1] [raid10] md0 : active raid5 sde1[4] sdb1[1] sdf1[3] sdc1[0] sdg1[5] sdd1[2] 9766924800 blocks super 1.2 level 5, 512k chunk, algorithm 2 [6/6] [UUUUUU] bitmap: 0/15 pages [0KB], 65536KB chunkです。

ご提示いただいた 

fstab と mdstat の情報を確認しました。RAID 5アレイ自体は正常に md0 として組まれていますが、現在の fstab 設定では「OSがRAIDの準備完了を待たずにマウントを試みて失敗している」可能性が高いです。 

以下の3ステップで確実に解決できます。

1. fstab の記述を「待機型」に修正

現在の設定 defaults 0 1 では、起動プロセスの非常に早い段階でマウントが行われます。これを systemd に「デバイスが現れるまで待つ」よう指示するオプションに変更します。

  • 修正前: UUID=c2bc4e5e-895c-45ea-b798-99e6fcc97b05 /mnt/nas10tb ext4 defaults 0 1
  • 修正後:textUUID=c2bc4e5e-895c-45ea-b798-99e6fcc97b05 /mnt/nas10tb ext4 defaults,nofail,x-systemd.device-timeout=30 0 2
    • nofail: 万が一RAIDが組めなかった時にOS起動が止まるのを防ぎます。
    • x-systemd.device-timeout=30: デバイスが認識されるまで最大30秒待機させます。
    • 末尾の 1 を 2 に変更: ルートパーティション以外のチェック優先度を下げます。 

2. mdadm設定の更新と initramfs への反映 

Ubuntuの起動初期段階（initramfs）でRAIDを正しく認識させるため、現在の構成情報を同期させます。これを怠ると、起動時に一時的に md127 など別の名前で認識され、UUIDでの紐付けが間に合わないことがあります。 

  1. 設定ファイルを現在の状態に更新:bashsudo mdadm --detail --scan | sudo tee /etc/mdadm/mdadm.conf
  2. 起動イメージを再生成:bashsudo update-initramfs -u

3. 原因の切り分け（確認用）

もし上記でも解決しない場合は、起動時に何が起きているかログで確認できます。 

  • エラーログの確認:bashjournalctl -b | grep nas10tb コードは注意してご使用ください。「Dependency failed」や「Timed out waiting for device」といったメッセージがあれば、やはりタイミングの問題です。

次に再起動する際、上記の設定変更が完了していれば自動でマウントされるはずです。 設定反映後に一度再起動を試してみてください。

やってみましたが、マウントされません。Feb 21 18:14:51 ubuntu-nas systemd[1]: Dependency failed for mnt-nas10tb.mount – /mnt/nas10tb.Feb 21 18:14:51 ubuntu-nas systemd[1]: mnt-nas10tb.mount: Job mnt-nas10tb.mount/start failed with result ‘dependency’.

「

Dependency failed」というエラーは、systemdが「マウントしようとしたが、その前提となるRAIDデバイス（md0）が時間内に準備されなかった」ことを示しています。

sudo mount -a で成功することから、RAID自体は正常ですが、OS起動の非常に早い段階でRAIDを組み立てるプロセスがスキップされている、あるいは間に合っていないのが原因です。

以下の「強制的」な解決策を試してください。

1. mdadmの自動組み立てを強制する

Ubuntuの最近のバージョンでは、mdadm の設定ファイルに不整合があると、起動時の自動組み立てを止めてしまうことがあります。

  1. /etc/mdadm/mdadm.conf をクリーンにする:
    一度ファイルを空にしてから、現在の正しい構成情報だけを書き込みます。bash# バックアップを取る sudo cp /etc/mdadm/mdadm.conf /etc/mdadm/mdadm.conf.bak2 # 基本設定とスキャン結果を書き込む echo "DEVICE partitions" | sudo tee /etc/mdadm/mdadm.conf sudo mdadm --detail --scan | sudo tee -a /etc/mdadm/mdadm.conf
  2. initramfsを再度、強制更新:bashsudo update-initramfs -u -k all

2. systemd のマウント順序を明示的に指定する

fstab の設定だけでは不十分な場合、systemdに対して「RAID管理サービスが完了してからマウントしてくれ」と明示します。

  • /etc/fstab を以下に書き換え:
    オプションに x-systemd.after=mdmonitor.service を追加します。textUUID=c2bc4e5e-895c-45ea-b798-99e6fcc97b05 /mnt/nas10tb ext4 defaults,nofail,x-systemd.device-timeout=30,x-systemd.after=mdmonitor.service 0 2

3. それでもダメな場合の最終手段（起動スクリプト）

特定のハードウェア構成でどうしても認識が遅れる場合、起動後に自動で mount -a を実行させるサービスを作ります。

  1. 新しいサービスファイルを作成:
    sudo nano /etc/systemd/system/mount-raid-fix.service
  2. 以下を貼り付け:ini[Unit] Description=Force Mount RAID after boot After=local-fs.target [Service] Type=oneshot ExecStart=/bin/mount -a RemainAfterExit=yes [Install] WantedBy=multi-user.target
  3. サービスを有効化:bashsudo systemctl daemon-reload sudo systemctl enable mount-raid-fix.service

まずは 手順1と2 をセットで実施し、再起動してみてください。

これらの手順を試した後もエラーが出る場合、起動直後の lsblk の結果（特にRAIDが md127 などに化けていないか）を確認させていただけますか？

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTSloop0 7:0 0 13M 1 loop /snap/canonical-livepatch/378loop1 7:1 0 74M 1 loop /snap/core22/2292loop2 7:2 0 48.1M 1 loop /snap/snapd/25935sda 8:0 0 223.6G 0 disk ├─sda1 8:1 0 1G 0 part /boot/efi└─sda2 8:2 0 222.5G 0 part /sdb 8:16 0 1.8T 0 disk └─sdb1 8:17 0 1.8T 0 part └─md0 9:0 0 9.1T 0 raid5 sdc 8:32 0 1.8T 0 disk └─sdc1 8:33 0 1.8T 0 part └─md0 9:0 0 9.1T 0 raid5 sdd 8:48 0 1.8T 0 disk └─sdd1 8:49 0 1.8T 0 part └─md0 9:0 0 9.1T 0 raid5 sde 8:64 0 1.8T 0 disk └─sde1 8:65 0 1.8T 0 part └─md0 9:0 0 9.1T 0 raid5 sdf 8:80 0 1.8T 0 disk └─sdf1 8:81 0 1.8T 0 part └─md0 9:0 0 9.1T 0 raid5 sdg 8:96 0 1.8T 0 disk └─sdg1 8:97 0 1.8T 0 part └─md0 9:0 0 9.1T 0 raid5 マウントされません

lsblk

 の結果を見ると、RAIDアレイ自体は正常に md0 として組み上がっています。それなのにマウントされないのは、**「systemdがUUIDを見失っている」か「ファイルシステムのチェック（fsck）で止まっている」**可能性が高いです。

特に10TBという大容量のため、起動時の微細なタイミングのズレが影響しています。

以下の手順で、fstab の記述を**「UUID」ではなく「デバイスパス」による指定**に切り替えて、依存関係を強制解決しましょう。

1. /etc/fstab の書き換え

UUIDでの指定がうまくいかない（認識が遅れる）場合、/dev/md0 という直接のパスを指定するのが最も確実です。

/etc/fstab を開き、対象の行を以下のように書き換えてください。

text

/dev/md0  /mnt/nas10tb  ext4  defaults,nofail,x-systemd.before=zfs-mount.service,x-systemd.device-timeout=60  0  0
  • ポイント:
    • UUID=... ではなく /dev/md0 を直接指定。
    • 末尾を 0 0 にして、起動時の fsck（ディスクチェック）をスキップ させます（これが原因でマウントがブロックされることが多いため）。
    • x-systemd.device-timeout=60: 待機時間をさらに伸ばします。

2. mdadm 設定を「名前」で固定する

OSが md0 という名前を確実に保持するようにします。

  1. /etc/mdadm/mdadm.conf を編集します。bashsudo nano /etc/mdadm/mdadm.conf コードは注意してご使用ください。
  2. ARRAY で始まる行の末尾に name=0 がなければ追加、あるいは以下のような形式になっているか確認してください。textARRAY /dev/md0 metadata=1.2 name=0 UUID=（あなたのRAIDのUUID） コードは注意してご使用ください。※ name=0 を入れることで、/dev/md0 として固定されやすくなります。
  3. 設定を反映:bashsudo update-initramfs -u

3. マウントポイントのパーミッション確認

念のため、マウント先が原因でないか確認します。

bash

sudo chown $USER:$USER /mnt/nas10tb

これで解決しない場合:
起動直後に mount コマンドを叩かずに、以下のコマンドの結果を見てください。

  • systemctl status mnt-nas10tb.mount

ここで「Time out」が出ているか、別のエラーが出ているかで最後の一手が決まります。まずは fstab の 0 1 を 0 0 に変えること を優先して試してみてください。

再起動後、自動でマウントされているか、または状況に変化はありましたか？

● mnt-nas10tb.mount – /mnt/nas10tb Loaded: loaded (/etc/fstab; generated) Active: active (mounted) since Sat 2026-02-21 18:33:12 JST; 1min 36s ago Where: /mnt/nas10tb What: /dev/md0 Docs: man:fstab(5) man:systemd-fstab-generator(8) Tasks: 0 (limit: 28608) Memory: 6.7M (peak: 7.2M) CPU: 66ms CGroup: /system.slice/mnt-nas10tb.mountFeb 21 18:33:12 ubuntu-nas systemd[1]: Mounting mnt-nas10tb.mount – /mnt/nas10tb…Feb 21 18:33:12 ubuntu-nas systemd[1]: Mounted mnt-nas10tb.mount – /mnt/nas10tb.マウントされました。

ついにマウントされましたね！良かったです。

結果を見る限り、今回の原因は「UUIDの解決タイミング」と「起動時のディスクチェック（fsck）」の合わせ技だった可能性が高いです。

大容量（10TB）のRAIDアレイの場合、起動時にOSが「このUUIDはどこだ？」と探している間にタイムアウトしたり、バックグラウンドでfsckが走ってマウントをブロックしたりすることがよくあります。

今回の設定のポイントをまとめておきます：

  • /dev/md0 直指定: UUIDの解決を待たずにデバイスに直結。
  • 末尾 0 0: 巨大なアレイの起動時チェックをスキップして即マウント。
  • タイムアウト延長: ストレージの回転やRAIDの組み立て時間を確保。

このまま運用して問題ありませんが、ディスクチェックをスキップする設定にしたので、数ヶ月に一度は手動でファイルシステムの整合性チェック（fsck）や、RAIDの不一致チェック（scrubbing）を行うことをおすすめします。

RAIDの健康状態チェック（たまに実行すると安心です）:

bash

# RAIDの不一致チェックを開始
echo check | sudo tee /sys/block/md0/md/sync_action

快適なNASライフを！他にお困りのことがあればいつでも聞いてください。