Ubuntu 26.04 remote fstab mount – fstab でリモートストレージを固定マウントする

Ubuntu 26.04 でリモートストレージを常時使う場合、fstab に定義して固定マウントする方法があります。NFS、CephFS、CIFS などのリモートファイルシステムを、サーバー起動後に決まったパスへマウントして使う構成です。

ただし、リモートストレージの fstab 定義は、ローカルディスクの fstab と同じ感覚で扱うと危険です。ネットワーク、名前解決、認証、ストレージサーバーの起動状態に依存するため、起動時の順序や失敗時の挙動を意識する必要があります。

remote fstab mount の位置づけ

remote fstab mount は、リモートストレージを固定パスへ常時マウントしたい場合に使います。ログ保存先、共有データ置き場、アプリケーションが常に参照するディレクトリなど、マウントされていることを前提にしたい用途に向いています。

重要なのは、fstab を使うこと自体ではなく、そのマウントが起動時に必須なのか、失敗しても起動を継続してよいのかを決めることです。

マウント先ディレクトリを作成する

fstab に定義する前に、マウント先ディレクトリを作成します。アプリケーションから使う場合は、所有者、グループ、権限も合わせて決めます。

sudo install -d -m 755 -o root -g root /mnt/remote-data
stat /mnt/remote-data

マウント先が存在しない状態で fstab に定義しても、マウントは失敗します。ディレクトリの権限は、マウント後のファイルシステム側の権限と混同しないようにします。

CephFS を fstab に定義する

CephFS を fstab で固定マウントする例です。実際の monitor、path、secretfile は環境に合わせます。

sudo tee -a /etc/fstab >/dev/null <<'EOF'
10.0.0.11,10.0.0.12,10.0.0.13:/ /mnt/remote-data ceph name=client.admin,secretfile=/etc/ceph/client.admin.secret,_netdev,noatime 0 0
EOF

_netdev は、ネットワーク越しのファイルシステムであることを示す option です。systemd 環境では、remote filesystem として扱われ、ローカルディスクとは異なる起動順序で処理されます。

NFS を fstab に定義する

NFS の場合も考え方は同じです。サーバー名で指定する場合は、名前解決が起動時に利用できることも前提になります。

sudo tee -a /etc/fstab >/dev/null <<'EOF'
nfs.example.internal:/export/share /mnt/remote-data nfs4 defaults,_netdev,nofail,x-systemd.automount 0 0
EOF

nofail を付けると、マウントに失敗しても起動全体を止めにくくなります。x-systemd.automount を付けると、アクセス時に自動マウントする構成にできます。常時必須のストレージなのか、起動後に必要になった時だけマウントすればよいのかで選びます。

option の意味を分けて考える

リモートマウントでは、option を増やせば安全になるわけではありません。起動時に必須なのか、失敗時に起動を止めるべきなのか、遅延マウントでよいのかを決めてから option を選びます。

systemd と remote-fs.target の関係

Ubuntu 26.04 では、fstab の内容から systemd の mount unit が生成されます。リモートファイルシステムは remote-fs.target と関係し、_netdev の有無や mount option によって扱いが変わります。

systemctl list-units --type=mount
systemctl list-units --type=automount
systemctl status remote-fs.target
systemd-escape -p --suffix=mount /mnt/remote-data

fstab に書いたから単純に mount コマンドだけで処理される、という理解では不十分です。systemd が unit として扱うため、状態確認も systemctl 側から見られます。

設定を反映して確認する

fstab を編集したら、いきなり再起動する前に構文と mount 動作を確認します。

sudo systemctl daemon-reload
sudo findmnt --verify --verbose
sudo mount /mnt/remote-data
findmnt /mnt/remote-data
df -hT /mnt/remote-data

findmnt --verify は fstab の確認に使えます。実際に mount して、期待した fstype、source、option になっているか確認します。

起動時に失敗する場合の見方

リモート fstab mount が起動時に失敗する場合、ストレージだけを疑うのではなく、ネットワーク、DNS、認証情報、systemd の依存関係を分けて確認します。

journalctl -b -u remote-fs.target --no-pager
journalctl -b | grep -i "mnt-remote"
systemctl status mnt-remote\x2ddata.mount
findmnt --target /mnt/remote-data

• ネットワークが起動する前に mount しようとしていないか
• 名前解決が起動時に利用できるか
• secretfile や credential file の権限が正しいか
• ストレージサーバー側が起動しているか
• firewall や ACL で必要な通信が遮断されていないか
• 失敗時に boot を止めるべき mount なのか

autofs と使い分ける

remote fstab mount と autofs は、どちらが上位という関係ではありません。用途が違います。

常に使うストレージは fstab、必要な時だけ使うストレージは autofs と考えると整理しやすくなります。

確認するポイント

• mount point が存在するか
• fstab の source、path、fstype、opts が正しいか
• _netdev を付けているか
• 失敗時に nofail が必要か
• automount にする必要があるか
• 再起動後に期待通り mount されるか
• アプリケーション起動順序と衝突しないか

まとめ

Ubuntu 26.04 でリモートストレージを fstab に定義する場合、単に mount 行を書くのではなく、起動時の依存関係と失敗時の挙動を設計する必要があります。特に NFS、CephFS、CIFS のようなネットワーク越しの filesystem では、ローカルディスクと同じ扱いにしないことが重要です。

_netdev、nofail、x-systemd.automount、remote-fs.target の意味を理解し、固定マウントにするのか、autofs に逃がすのかを用途ごとに決めると、起動時トラブルを減らせます。

参考書籍

関連記事

Ubuntu 26.04 remote autofs mount – 必要な時だけリモートストレージをマウントする Ubuntu 22.04 NFS クライアント設定 – mount と fstab の基本 Ubuntu 26.04 fstab の基本 – ローカルディスクと永続マウントを安全に管理する Ubuntu 22.04 Docker ボリュームの使い方 – bind mount と volume の違い Ubuntu 26.04 autofs の基本設定 Ubuntu 26.04 NFS マウントの基本設定 Ubuntu 26.04 Nginx の基本設定 – Web サーバーを起動して確認する Ubuntu 26.04 NFS の基本設定