Linuxで追加のHDD・SSDを起動時に自動マウントするには、対象のファイルシステムをUUIDで特定し、/etc/fstabに登録します。systemd環境では、アクセスされたときだけマウントする設定も可能です。大切なのは、設定を追加した直後に再起動するのではなく、設定ファイルの検証、対象だけのマウント、実際の接続先の確認を順番に行うことです。
本記事は、すでにファイルシステムがあり、正常に利用できる追加のデータディスクを対象にします。基本例はext4です。初期化・フォーマットやパーティション変更は行いません。/、/boot、EFIシステムパーティション、既存の/home・/var、swapの設定変更や移行には、この例をそのまま使わないでください。暗号化・RAID・LVM・ネットワークストレージは、それぞれの構成に応じた手順も必要です。
Linuxにおけるディスクマウントの基本
マウントとは、ディスク上のファイルシステムをLinuxのディレクトリツリーにつなぐ操作です。たとえば追加ディスクを/mnt/dataにマウントすると、そのディスクの内容をこのディレクトリから利用できます。この接続先を「マウントポイント」と呼びます。マウントはフォーマットとは異なり、既存のファイルシステムを作り直す操作ではありません。
ただし、マウント先に元からファイルがあると、そのファイルはマウント中に見えなくなります。削除されたわけではありませんが、見間違いや誤った場所への保存を防ぐため、用途を決めた空のディレクトリを使います。シンボリックリンクや、ほかの用途・ユーザーが管理するディレクトリを安易に指定しないでください。
- 手動マウント:
mountでその場で接続します。それだけでは次回起動時の設定になりません。 - 起動時マウント:
/etc/fstabに登録し、起動処理で接続します。 - オンデマンドマウント:systemdのautomountを使い、パスへのアクセス時に接続します。「USBを挿した瞬間にマウント」とは別の仕組みです。
デスクトップのファイルマネージャーがすでに外付けディスクをマウントしている場合もあります。同じディスクを別の場所に重ねて設定する前に、現在の接続先を確認しましょう。
ステップ1:UUID・ファイルシステム・現在の接続先を確認する
まずは情報を表示するだけのコマンドで、容量、型番、ファイルシステム、UUID、既存のマウント先を照合します。/dev/sdaや/dev/sdbという名前だけで対象を決めないでください。
lsblk -o NAME,SIZE,MODEL,FSTYPE,UUID,MOUNTPOINTSMOUNTPOINTSに対応していない古い環境では、lsblk --helpで利用できる列を確認し、MOUNTPOINTも参考にします。lsblkの列と意味は、util-linuxのlsblk(8)で確認できます。
候補が見つかったら、そのファイルシステムの情報を個別に確認します。次の/dev/sdb1は例です。必ず直前の表示で確認した実際のパーティションまたは論理デバイスに置き換えてください。
sudo blkid /dev/sdb1TYPE="ext4"なら、この記事のext4例の対象です。xfs、ntfs、exfatなどをext4と書き換えて使うことはできません。crypto_LUKS、LVM2_member、linux_raid_memberなどは、直接マウントする通常のファイルシステムとは異なります。適切に解除・構成された論理デバイス側を確認します。- UUIDやFSTYPEが空欄でも、「空のディスク」と判断して初期化してはいけません。識別できない場合は設定を止めます。
- すでに利用中のマウント先が表示されたら、その用途と利用中のアプリを確認します。使用中のディスクを設定検証のために強制的にアンマウントしないでください。
UUIDは、デバイス名が接続順で変わる問題を避けるために有用です。ただし絶対に不変・重複しない識別子ではありません。再フォーマットや管理操作で変わることがあり、ディスクの複製で重複することもあります。複製ディスクを接続している場合は、容量・型番・UUIDを改めて照合します。同じUUIDを持つ別のディスクが見つかった場合は、このUUID指定の手順を進めず、対象を一意に識別できる構成に整理してから設定してください。UUIDの文字列は表示結果どおりに使用してください。参照:mount(8)のデバイス識別。
ステップ2:マウントポイントとfstabのバックアップを用意する
ここからはシステム設定を変更します。重要なデータは別途バックアップし、サーバーなら利用者・稼働サービスへの影響を確認してください。以降は/mnt/dataを新しい接続先として使う例です。すでに存在する場合は、内容と用途を調べてから利用を判断します。
/mnt/dataが存在しない場合だけ、次のコマンドで作成します。「すでに存在する」というエラーが出たときは、そのまま作業を進めず確認してください。
sudo mkdir /mnt/data既存のマウントとディレクトリの内容を確認します。findmnt --mountpointに対象が出ないことだけでは、ディレクトリが空であるとは限りません。
findmnt --mountpoint /mnt/data
sudo ls -la /mnt/dataすでに別のファイルシステムがマウントされている、ファイルが入っている、シンボリックリンクである場合は、別の未使用の接続先を選ぶか、管理者と用途を整理します。既存のautomountがある場所では、ディレクトリの参照自体がマウントを起動する場合もあります。
次に/etc/fstabを日時付きで保存してから編集します。このコピーは設定ファイルのバックアップであり、ディスク内のデータをバックアップするものではありません。作成されたファイル名を控えておきます。
sudo cp -a /etc/fstab "/etc/fstab.backup.$(date +%Y%m%d-%H%M%S)"
sudoedit /etc/fstab既存の行をまとめて置き換えず、対象ディスク・マウント先がすでに登録されていないことを確認して、必要な1行だけ追加または修正します。
/etc/fstabの6項目を理解する
/etc/fstabは、マウントする対象・場所・方法を記録する設定ファイルです。次の行はext4のデータディスク用の記入例であり、シェルで実行するコマンドではありません。REPLACE_WITH_EXT4_UUIDは、確認した実際のUUIDに置き換えます。
UUID=REPLACE_WITH_EXT4_UUID /mnt/data ext4 defaults 0 2- 1:UUID。対象のファイルシステムを特定します。
- 2:マウントポイント。例では
/mnt/dataです。 - 3:種類。実際のファイルシステムに合わせます。
- 4:オプション。
defaultsは既定の動作を使う指定です。一般に読み書き可能ですが、実効オプションはカーネルやファイルシステムにも依存します。 - 5:dump用の指定。通常は
0です。一般的なバックアップソフトの有効・無効を切り替える欄ではありません。 - 6:起動時チェック用の指定。このext4データディスク例では
2です。0はこの欄によるチェックを行わない指定です。
第6項目は、すべてのファイルシステムに一律で2を設定するものではありません。たとえばXFSは通常0とし、fsck.xfs自体は修復を行いません。またsystemdは、この数値を厳密な通し番号の起動順として扱いません。既存のシステム用エントリは変更せず、種類とディストリビューションの方針に合わせます。参照:fstab(5)、systemd-fstab-generator、fsck.xfs(8)。
項目は半角スペースまたはタブで区切り、オプション同士は空白を入れずにカンマでつなぎます。パス中の空白には\040などのエスケープが必要なので、初めは空白のない接続先が分かりやすいでしょう。
ステップ3:再起動せずに設定を検証する
まずはfindmntで設定ファイルを検証する
保存後、最初に次のコマンドを実行します。これはfstabの構文や利用可能性を調べるもので、実際のマウントを行うコマンドではありません。エラーや警告が出た場合は、UUID、種類、マウント先、オプション、重複行を確認します。
sudo findmnt --verify --verboseデバイス未接続の警告と入力ミスは区別が必要です。この検証を通っても、実際のマウント成功や次回起動の成功まで保証されるわけではありません。参照:findmnt(8)。
systemdへ反映し、対象の1か所だけをマウントする
systemdを使っている環境では、fstab変更後に設定を再読み込みします。これは既存のマウントをやり直したり、ディスクをマウントしたりする操作ではありません。systemdを使わない環境では、このコマンドは不要です。
sudo systemctl daemon-reload対象ディスクが正常で、ほかの場所でも利用されておらず、/mnt/dataも未マウントであることを確認したら、通常の起動時マウントの設定は次のように対象だけを指定して試します。これは実際にディスクをマウントする操作です。読み書き可能なマウントでは、ファイルシステム側の更新が発生し得ます。
sudo mount /mnt/data
findmnt --mountpoint /mnt/data -o SOURCE,TARGET,FSTYPE,OPTIONS
lsblk -o NAME,FSTYPE,UUID,MOUNTPOINTSfindmntの接続元とlsblkのUUIDを照合し、意図したディスクが、意図した場所に、意図した種類・オプションで接続されたことを確認します。df -hは容量確認には便利ですが、それだけで正しいディスクと判断しないでください。findmnt --target /mnt/dataは未マウント時にも親ファイルシステムを返し得るため、ここでは接続先を厳密に指定する--mountpointを使っています。
mount -aは構文チェックではありません。fstab内の対象エントリをまとめてマウントしようとするため、ほかのディスクやネットワークストレージにも作用します。また、すでにマウント済みのものは通常スキップされ、変更後のオプションを検証できない場合があります。設定の確認にはfindmnt --verifyを使い、実動作は対象だけで確認しましょう。
以上の「UUIDの確認 → fstab編集 → daemon-reload → 対象だけのマウント」は、Red Hatの永続マウント手順でも確認できます。再起動確認は、エラーがなく、必要なデータへのアクセスと復旧手段を確保できてから、メンテナンス可能な時間に行います。SSH接続しかないサーバーで、復旧用コンソールを用意せずに再起動しないでください。
外付けHDDにはnofailを使うべきか
外付けHDDなど、接続されていない状態でもOSを起動したい任意のデータディスクでは、通常マウントの例を次の1行に変更する選択肢があります。同じマウント先の行を追加して二重登録するのではなく、どちらか一方を使います。
UUID=REPLACE_WITH_EXT4_UUID /mnt/data ext4 defaults,nofail,x-systemd.device-timeout=10s 0 2systemd環境でのnofailは、そのマウントの成功を起動の必須条件にせず、マウント完了を待たずに起動処理を進める指定です。「マウントを試さない」「故障が直る」「アプリが必ず使える」という意味ではありません。x-systemd.device-timeout=10sはデバイス出現を待つ時間の例です。認識に時間がかかる機器には短すぎる場合があるため、実機に合わせて調整します。これはマウント処理自体の時間制限とは別です。
注意したいのは、ディスクがないのに処理が続くことです。通常のマウントに失敗すると、/mnt/dataがOS側の単なるディレクトリとして残り、バックアップやアプリがそこに書き込んでOSディスクを満杯にする可能性があります。ディスクを必須とするサービスでは、安易にnofailにせず、マウント成功を起動条件にします。systemdサービスではRequiresMountsFor=/mnt/dataなどの依存関係を設計し、必要に応じて実際の接続元も確認します。参照:systemd.unitのRequiresMountsFor=。
systemdでアクセス時に自動マウントする
systemd環境では、通常はfstabの設定からマウントユニットが生成されます。アクセス時だけマウントしたい場合も、最初からユニットファイルを手書きする必要はありません。以下は、任意のext4データディスク用にx-systemd.automountを加えた代替例です。前のfstab例と重ねて登録しないでください。
UUID=REPLACE_WITH_EXT4_UUID /mnt/data ext4 defaults,nofail,x-systemd.automount,x-systemd.device-timeout=10s 0 2変更後はfindmnt --verify --verboseとsystemctl daemon-reloadを行います。ここでは、対象がすでにマウント済みなら無理に解除して試さず、利用中のアプリを終了できるメンテナンス時間を確保します。未マウントかつ未使用の接続先で、生成されたautomountを開始してアクセス時の動作を確認します。
sudo systemctl start mnt-data.automount
systemctl status mnt-data.automount --no-pager
ls /mnt/data
findmnt --mountpoint /mnt/data -t ext4 -o SOURCE,TARGET,FSTYPE,OPTIONS
systemctl status mnt-data.mount --no-pagermnt-dataは/mnt/dataに対応する名前です。別の接続先では名前も変わります。fstabから生成されたユニットに対して、手書きユニットと同じようにsystemctl enableを実行する必要はありません。起動時の関係はfstabから生成されます。
- automountの待ち受けが有効なだけでは、実ディスクが接続されたことになりません。アクセス前に
autofsが見えるのは待ち受け側です。上の例ではアクセス後に-t ext4で実際のマウントを確認します。 - ディスクがなければ、アクセスした処理は待機した後に失敗する場合があります。バックアップやアプリ側でも失敗を検出する必要があります。
x-systemd.automountと組み合わせた場合、systemdではauto・noautoはautomountの起動制御に使えません。- 必要なら
x-systemd.idle-timeout=5minなどを追加できますが、アイドル時のアンマウントを試みる機能であり、使用中でも必ず解除するものではありません。安全な取り外しの代わりにもなりません。 - これらの
x-systemd.*オプションはsystemd向けです。使用中のOSのマニュアルで対応を確認してください。
動作と各オプションの定義は、systemd.mountとsystemd.automountを参照してください。
応用:.mountと.automountを直接作成する場合
ユニットファイルで管理する運用も可能です。ただし、同じ接続先をfstabと手書きユニットの両方で管理しないようにします。/etc/systemd/system/の手書きユニットが優先され、fstabを直しても反映されない原因になります。通常のデータディスクは、まずfstab方式を選ぶと管理しやすいでしょう。
以下は構造を理解するためのext4の最小例です。手書きの.mountにはfstabの第6項目に相当する設定がなく、必要なファイルシステムチェックの依存関係などは別途設計します。この2ファイルだけで、前述のfstab設定とすべて同じ動作になるわけではありません。
/etc/systemd/system/mnt-data.mount:
[Unit]
Description=Data disk mount
[Mount]
What=/dev/disk/by-uuid/REPLACE_WITH_EXT4_UUID
Where=/mnt/data
Type=ext4
Options=defaults/etc/systemd/system/mnt-data.automount:
[Unit]
Description=Data disk automount
[Automount]
Where=/mnt/data
TimeoutIdleSec=0
[Install]
WantedBy=multi-user.targetファイル名は接続先のパスから決まります。ハイフンなどを含む名前では単純なスラッシュ置換だけで作れないため、systemd-escapeで確認します。
systemd-escape --path --suffix=mount /mnt/data
systemd-escape --path --suffix=automount /mnt/dataこの手書き方式を選び、UUIDの置換、fstabとの重複解消、未使用の接続先、必要な依存関係まで確認できた場合に限り、次のようにautomount側を有効化します。アクセス時にマウントさせたいので、.mountを別途enableして起動時マウントにしないようにします。
sudo systemctl daemon-reload
sudo systemctl enable --now mnt-data.automountTimeoutIdleSec=0はアイドル時の自動解除を無効にする指定です。また、fstab用のx-systemd.device-timeout=を手書き.mountのOptions=に移しても同じ設定にはなりません。細かな待機時間やチェック処理まで必要なら、安易に省略せずユニット設計を確認してください。
マウントできても書き込めないとき:権限と種類を分けて考える
「マウントできる権限」と「ファイルを書き込める権限」は別です。まず、想定したディスクが実際にマウントされていることを確認してから、対象フォルダーの所有者・グループ・権限を調べます。
findmnt --mountpoint /mnt/data -o SOURCE,TARGET,FSTYPE,OPTIONS
id
ls -ld /mnt/data- ext4・XFSなど:ファイルシステム内の所有者、グループ、パーミッション、ACLなどが効きます。必要な作業用サブディレクトリだけに適切な権限を設定します。
uid=やgid=をext4の汎用マウントオプションとして追加しても解決しません。 - FAT・exFAT・NTFSなど:利用するドライバーに応じて、
uid、gid、umask、fmask、dmaskなどの指定を確認します。利用者のUIDが必ず1000とは限らず、NTFSもntfs3とntfs-3gで扱いが異なります。 - 避けたい対処:原因不明のままディスク全体へ再帰的な所有者変更や
chmod 777を適用しないでください。既存データのアクセス制御を壊す可能性があります。 - SELinuxなど:通常の権限が正しくても、サービス側の制限やセキュリティポリシーでアクセスできない場合があります。保護機能を無効化する前にログを確認します。
NTFSディスクをWindowsと共有している場合は、休止状態や高速スタートアップも確認が必要です。読み取り専用になったからといって強制マウントや休止情報の削除で回避せず、Windows側で正常終了した状態にしてから確認します。参照:LinuxカーネルのVFAT資料、NTFS3資料、Debianのntfs-3g(8)。
エラー対処法:再起動や修復の前に確認すること
UUIDが見つからない・wrong fs typeなどで失敗する
ディスクの接続、lsblkとblkidの表示、fstabのUUIDと種類を再確認します。マウントオプションの誤りや、必要なドライバー・マウントヘルパーがない場合もあります。エラーメッセージだけで「未フォーマット」と決めつけてはいけません。systemd環境では、次の読み取り用コマンドで対象ユニットとカーネルのログを確認します。
systemctl status mnt-data.mount --no-pager
sudo journalctl -b -u mnt-data.mount --no-pager
sudo journalctl -k -b --no-pager起動が遅い・外付けディスクがないと起動に影響する
そのディスクが必須か任意かを先に判断します。任意なら前述のnofailやデバイス待機時間、オンデマンド方式を検討します。必須のデータを使うサービスは、マウントできない状態で動かさない設計が必要です。NFS・SMBなどは本記事のローカルディスク例とは別に設定し、_netdevだけで通信先や認証の成功まで保証されるとは考えないでください。
読み取り専用になる・I/Oエラーが出る
書き込みを増やさず、接続・電源・ストレージの状態とログを確認します。マウント中のファイルシステムに修復コマンドを実行しないでください。修復の必要性は、バックアップ、対象の特定、アンマウント可能なメンテナンス環境を確保してから判断します。ext4、XFS、NTFSなどでは検査・修復ツールと手順が異なり、fsckを一律に実行すればよいわけではありません。物理故障が疑われる場合は、繰り返し修復を試すよりデータ保全を優先します。参照:e2fsck(8)の実行条件。
設定を戻したい・変更が反映されない
再起動する前なら、まず今回追加・変更した行だけを元に戻すか、追加行の先頭を#にして無効化します。バックアップ全体を復元する場合は、その後に行われた別の正当な変更まで消さないよう差分を確認します。戻した後もfindmnt --verify --verboseを実行し、systemd環境ではdaemon-reloadを行います。
fstabの行を消しただけでは、現在のマウントや稼働中のautomountは解除されません。利用中の処理を停止できることを確かめたうえで、該当ユニットの停止やアンマウントを別途計画してください。手書きユニットを使った場合は、その有効化状態も見直します。無理な強制アンマウント、原因不明の再起動、設定ファイル全体の置き換えは避けます。
まとめ
自動マウントは、UUIDをfstabへ書くだけで終わりではありません。対象ディスクと既存の利用状況を確かめ、設定をバックアップし、findmnt --verifyで検証してから、対象だけを実際にマウントします。systemd環境では変更後のdaemon-reloadも忘れないようにしましょう。
常時接続の必須ディスク、外付けの任意ディスク、アクセス時だけ使うディスクでは適切な設定が異なります。nofailやautomountの便利さだけでなく、ディスクがないときにアプリがどう動くかまで確認すると、起動トラブルや誤った保存先への書き込みを防ぎやすくなります。


コメント