「Read-only file system」の対処 - 再マウントとfsck

2026-06-05 読了時間: 約11分 難易度: 中級

「Read-only file system」とは何が起きているのか？

結論: 書き込みが Read-only file system（EROFS）で拒否される状態。意図的な ro マウントか、カーネルが I/O エラーを検知して保護的に read-only へ落としたかのどちらか。

touch や vi の保存、ログ書き込みが次のように弾かれる。

touch: cannot touch '/var/log/app.log': Read-only file system

原因は大きく 3 系統に分かれる。切り分けの優先順位もこの順。

• A. カーネルが障害検知で ro 化（最重要）— ext4 の既定 errors=remount-ro により、I/O エラーやメタデータ破損を検知すると保護のため read-only へ自動降格する
• B. 意図的な ro マウント — /etc/fstab の ro 指定、CD-ROM/SquashFS、コンテナの読み取り専用ボリューム
• C. ファイルシステム破損 — fsck が必要な不整合。多くは A を経由して顕在化する

まず現状を確認するには？

結論: findmnt で対象が本当に ro かを確認し、dmesg で ro 化の原因（I/O エラーかメタデータ破損か単なる設定か）を特定する。原因確認なしの書き戻しは禁物。

1. 本当に read-only か確認する

findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS /

TARGET SOURCE    FSTYPE OPTIONS
/      /dev/sda1 ext4   ro,relatime,errors=remount-ro

OPTIONS 先頭が ro なら read-only。/proc/mounts を直接見てもよい。

grep ' / ' /proc/mounts

2. なぜ ro になったかを dmesg で確認する

ここが切り分けの核心。出力でハードウェア I/O エラーが見えるかどうかで対応が分岐する。

dmesg -T | grep -iE 'ext4-fs|i/o error|remount|read-only|critical'

[Thu Jun  5 09:12:44 2026] EXT4-fs error (device sda1): ext4_journal_check_start:84: Detected aborted journal
[Thu Jun  5 09:12:44 2026] EXT4-fs (sda1): Remounting filesystem read-only
[Thu Jun  5 09:12:43 2026] blk_update_request: I/O error, dev sda, sector 12869632

• I/O error / blk_update_request が出ている → ディスク障害を疑う（後述）
• EXT4-fs error のみでハード I/O エラーなし → 破損。fsck が必要（後述）
• 何も出ない → 設定起因の ro。/etc/fstab を確認

一時的に read-write へ戻すには？（remount）

結論: 設定起因や軽微な一過性なら mount -o remount,rw / で即復帰できる。ただし I/O エラーや破損が原因のときは書き戻し自体が危険なので、dmesg 確認後に限る。

原因が「fstab の ro 指定」や「一過性で I/O エラーなし」と確認できた場合のみ実行する。

sudo mount -o remount,rw /

特定パーティションなら対象を明示する。

sudo mount -o remount,rw /var

成功すれば findmnt の OPTIONS が rw に変わる。remount,rw が EROFS や cannot remount ... read-write で失敗する場合、下層で I/O エラーまたは破損が起きているサインなので、無理に繰り返さず fsck/ディスク診断へ進む。

ファイルシステム破損を修復するには？（fsck）

結論: fsck はアンマウント状態で実行するのが鉄則。マウント中の fs に fsck をかけると破損を悪化させる。ルートは Live USB かレスキューモードから修復する。

なぜマウントしたまま fsck してはいけないのか

fsck はブロックを直接書き換える。マウント中（特に rw）の fs を裏で書き換えると、カーネルのキャッシュと不整合になりデータを破壊する。ro マウント中でも非推奨。必ず unmount するか、ルートなら別環境から起動する。

非ルートパーティションの場合

sudo umount /dev/sdb1
sudo fsck -y /dev/sdb1

• -y: 確認に自動で yes（大量の質問を省く）
• -f: クリーン状態でも強制チェック
• ext4 なら fsck.ext4（= e2fsck）が呼ばれる

ルートファイルシステムの場合

ルートは稼働中アンマウントできない。次のいずれかで修復する。

1. Live USB / レスキューメディアから起動 → ルートを未マウントのまま fsck -y /dev/sda1
2. 次回起動時の自動 fsck を予約して再起動

# 次回ブート時に強制 fsck（systemd 環境）
sudo fsck.mode=force  # カーネルパラメータでの指定例
# 従来法: ルートに fsck 予約フラグを立てる
sudo tune2fs -l /dev/sda1 | grep -i 'mount count'
sudo touch /forcefsck   # 古典的だが systemd では非対応のことがある

修復後はマウントして書き込みできるか確認する。

sudo mount /dev/sdb1 /mnt && touch /mnt/.write-test && rm /mnt/.write-test

ディスク障害を疑うべきとき

結論: dmesg に I/O error やセクタ番号が出たら物理障害の可能性が高い。smartctl で健康度を確認し、劣化していれば fsck より先にデータ退避を優先する。

dmesg でハード I/O エラーを観測したら、修復より先にディスクの状態を確認する。

sudo smartctl -a /dev/sda | grep -iE 'health|reallocated|pending|uncorrect'

SMART overall-health self-assessment test result: FAILED!
  5 Reallocated_Sector_Ct   0x0033   100   100   010    -   384
197 Current_Pending_Sector  0x0012   100   100   000    -   16

• FAILED / Reallocated_Sector_Ct や Current_Pending_Sector の増加 → 物理劣化。fsck は一時しのぎにしかならない
• この段階では書き込み（fsck の修復書き込み含む）がトドメになり得る。読み取り専用のまま dd/rsync でバックアップを最優先にする

再発を防ぐには

結論: errors=remount-ro は障害を握り潰さず可視化する安全設計。これを活かし、SMART 監視と空き容量・inode 監視で「ro 化する前」に異常を検知する体制を作る。

• errors=remount-ro を維持: ext4 既定。errors=continue に弱めると破損を放置して被害が拡大する
• smartd（smartmontools）で常時監視: 不良セクタ増加を ro 化前にメール通知
• 容量・inode の枯渇を監視: 枯渇起因の書き込み失敗は別問題。ディスクがいっぱいの調べ方とinode 枯渇の対処を参照
• 定期 fsck: tune2fs -c <N> でマウント回数ベースの自動チェックを設定