USB接続ストレージがなぜかマウントされない話（失敗談）

Linux

2026.02.23

Ubuntuでファイルサーバーを組んでいて、再起動後に「なぜかストレージにアクセスできない」「パーミッションが戻っているように見える」という現象にハマりました。

fstab にはちゃんと書いているはずなのに、mount を見ると載っていない。今回はその原因と、最終的にどう解決したかを整理しておきます。

何が起きていたのか

今回の構成では、物理ディスクのマウントポイントとは別に、用途ごとに分かりやすいパスを用意したかったため bind マウントを使っていました。

具体的には、実体となるストレージは /srv/data001 や /srv/data02 のように管理用としてまとめ、Samba や日常的なアクセスでは /srv/share や /srv/6tb といった用途名のディレクトリを使う、という意図です。

こうしておくと、

・物理ディスクの入れ替え時に Samba 側のパスを変えずに済む
・内部構成（data01, data02 など）を意識せずに使える
・将来的に別ストレージへ差し替えても bind 先を維持できる

といったメリットがあります。

いわば「内部実装と公開パスを分離する」ための構成で、設計自体はよくあるものです。

構成はこんな感じです。

・内蔵ストレージ（1TB）：/srv/data001 → bind して /srv/share
・外付けUSBストレージ（6TB）：/srv/data02 → bind して /srv/6tb

fstab には両方とも ext4 のマウントと bind マウントを記述していました。

ところが再起動後に mount | grep srv を見ると、内蔵ストレージ側は問題なくマウントされているのに、外付けストレージ側だけが完全に消えている状態でした。

/srv/6tb は存在するけど中身は空、権限も root:root に戻ったように見える、という状況です。

最初は以下を疑いました。

・chmod / chown が保存されていない？
・fstab の UUID が間違っている？
・bind マウントの書き方がおかしい？

ただ、lsblk -f を確認すると USB ストレージ自体は正しく認識されていて、UUID も一致していました。つまり「ディスクは見えているが、マウントされていない」状態です。

原因は systemd の起動順と、USB ストレージの認識タイミングでした。

内蔵ストレージは起動初期から常に存在するため、fstab の ext4 マウント → bind マウントが問題なく通ります。一方、USB 接続ストレージは起動中に少し遅れて認識されることがあります。

その結果、systemd が fstab を処理した時点では USB ディスクがまだ存在せず、マウントが失敗します。そして重要なのは、systemd は「一度失敗したマウントを後から自動でやり直さない」という点です。

つまり、

・起動時に一瞬存在しなかった
・マウント失敗として確定
・起動はそのまま続行
・後から USB が認識されても再試行されない

という流れになります。

さらにややこしかったのが bind マウントです。

bind マウントは、元となるマウントが存在しないと即座に失敗します。ext4 単体なら後から成功していた可能性があっても、bind が絡むと依存関係ごと失敗扱いになります。

その結果、実体がマウントされていない /srv/6tb を見て

「権限が戻ってる」「chmod が効かない」

と勘違いしていましたが、実際には単に何もマウントされていなかっただけでした。

解決策は、fstab に systemd 用のオプションを追加して、順序と依存関係を明示することでした。

USB ストレージ側の記述を以下のように変更しました。

UUID=xxxx /srv/data02 ext4 defaults,x-systemd.requires=/srv 0 2
/srv/data02 /srv/6tb none bind,x-systemd.after=/srv/data02 0 0

これで systemd は

という順序を理解します。

変更後に mount -a を実行し、mount | grep srv で確認すると、期待通り両方ともマウントされるようになりました。

・chmod / chown は bind 先ではなく「実体側」に行う
・fstab に書いてある = マウントされている、ではない
・USB / ネットワーク / bind が絡む場合は順序指定を疑う
・mount -a はトラブル時の必須チェック

今回の原因は、USB 接続ストレージの認識が起動時に間に合わず、systemd がマウント失敗のまま起動を続行していたことでした。権限や UUID の問題ではなく、単純に「存在しなかったものとして扱われていた」だけです。

fstab は宣言ではなく、起動時のジョブ定義に近いものだと理解すると、この挙動はかなり腑に落ちます。外付けストレージを使ったファイルサーバー構成では、最初から systemd の順序指定を入れておくのが安全だと感じました。