データ復旧の情報工学研究所

　
株式会社情報工学研究所
お申し込みフォーム
お問合わせフォーム

CentOS EROFS (30) 対策：読み取り専用ファイルシステムエラー「Read-only file system」発生時の再マウントと設定変更対策編

最短チェック
CentOSでEROFS(30)が出たら：再マウント可否と設定の当たり所
「いま書けない」の原因を先に切り分け、影響を広げずに最小変更で収束させます。
1 30秒で原因を絞る
「誰が」「どのパスで」「どのマウントが」読み取り専用になっているかを先に特定します。
id


namei -l /問題のパス
ls -ld /問題のディレクトリ /マウントポイント
findmnt -no TARGET,SOURCE,FSTYPE,OPTIONS /問題のパス
2 症状別：いまの失敗に合う最短コマンド
A. 直前まで書けたのに突然EROFS：自動でroへ切替の疑い
まずログで根本原因を確認し、安易な書込み再開で悪化させないようにします。
dmesg -T | tail -n 120


journalctl -k -b | tail -n 200
grep -iE "read-only|EXT4-fs error|XFS.*corrupt|I/O error|Buffer I/O error" /var/log/messages 2>/dev/null | tail -n 80
B. ro指定の設定が原因：fstabやmount単位の見直し
設定にroが入っていると、再起動後も繰り返します。まず「設定の存在」だけを確認します。
findmnt -no TARGET,OPTIONS /問題のパス


grep -nE "^[^#].*\s(ro|defaults,ro)\s" /etc/fstab
systemctl list-units --type=mount
C. 一時しのぎが可能か確認：再マウントの成否を短時間で見る
再マウントが通らない場合は、ファイルシステム障害や下位I/Oの疑いが濃くなります。
touch /tmp/ro_test 2>&1 | tail -n 1


sudo mount -o remount,rw /対象マウント 2>&1 | tail -n 2
findmnt -no TARGET,OPTIONS /対象マウント
touch /tmp/ro_test 2>&1 | tail -n 1
D. 共有・コンテナ境界の見落とし：ホストはrwでも中がroのケース
bind mountやnamespaceの差で、見えているオプションが変わることがあります。
findmnt -R /対象パス


cat /proc/mounts | grep -E " /対象マウント | ro," | head -n 20
lsns -t mnt 2>/dev/null | head -n 10
3 直す前に：影響範囲を1分で確認（やり過ぎ防止）
どのマウントがroで、どのプロセスが使っているかを確認して、変更範囲を絞ります。
findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS | sed -n "1,60p"


mount | awk "/ ro[ ,]/{print}" | head -n 40
df -hT
lsblk -f
lsof +f -- /対象マウント 2>/dev/null | head -n 30
失敗するとどうなる？（やりがちなミスと起こり得る結果）
・権限を広げすぎる → 情報漏えい/改ざん
・所有者を変えすぎる → 二次障害（停止・エラー連鎖）
・ACL/保護設定を無造作に外す → 監査指摘/再発/追跡不能
・共有/NFS/コンテナ境界の見落とし → 復旧長期化
迷ったら：無料で相談できます
情報工学研究所へ無料相談で、判断の迷いを早く収束させやすくなります。
・再マウントを試すべきか、ログの読み取りができない。
・どのマウントポイントがroなのか切り分けで迷ったら。
・fstabの設定変更が本番影響にならないか判断できない。
・ディスクI/Oエラーが疑わしいが、停止判断ができない。
・LVM/RAID/仮想化ストレージ配下で、どこから調べるべきか迷ったら。
・共有ストレージ、コンテナ、本番データ、監査要件が絡む場合は、無理に権限を触る前に相談すると早く収束しやすいです。
・NFSやbind mountの境界が分からず、触る範囲の診断ができない。
詳しい説明と対策は以下本文へ。

もくじ

【注意】 「Read-only file system（EROFS 30）」は“Linuxが勝手に意地悪している”のではなく、ディスク/RAID/SAN/仮想基盤など下位層の異常を検知して、データ破壊を被害最小化するために読み取り専用へ切り替わる典型パターンです。むやみに再マウントや再起動を繰り返すと、障害の拡大・ログ消失・復旧難度の上昇につながることがあります。個別環境（RAID構成、ファイルシステム種別、仮想化、DB/ミドルウェア、運用制約）によって最適解は変わるため、判断に迷う場合は株式会社情報工学研究所のような専門事業者に相談し、状況に合った切り分け・復旧手順を設計してください。

　

第1章：突然の「Read-only file system」— いつものデプロイが全部失敗する朝

夜間の定期デプロイ、設定反映、ログローテーション、どれも同じ症状で落ちる。「ファイルを書けない」「touchできない」「ログが吐けない」。そして端末には、見慣れたようで胃が重くなるメッセージが並びます。

Read-only file system / EROFS (30)

現場の頭の中はだいたいこうです。「え、rootが読めるのに書けない？」「アプリのバグ？権限？」「とりあえず再起動すれば戻る…？」。この“とりあえず”が、あとで効いてくることがあります。読み取り専用は、Linuxが“書き込みを許すと危ない”と判断した結果である場合が多く、そこを無視して動かすほど、障害の収束が遠のくからです。

まず起きていること：アプリではなく「マウント状態」の変化

EROFSは、多くの場合「OSが対象ファイルシステムを読み取り専用（ro）として扱うようになった」状態を指します。アプリケーションの権限不足（EACCES）やディスク容量不足（ENOSPC）とは別物です。プロセスは普通に動いて見えても、書き込み系のシステムコールが失敗し続けるため、次のような二次障害が雪だるま式に起こります。

  • ログが書けず、原因追跡の材料が消える（もしくはメモリ上で詰まって落ちる）
  • PIDファイルやソケットの生成に失敗して再起動ループに入る
  • DBがチェックポイントを書けず、整合性が悪化する
  • 設定管理ツールが失敗し、差分が中途半端に残る

ここで重要なのは、“いま出ているエラー”より、“なぜOSがroにしたのか”です。読み取り専用は結果であり、根っこにはI/Oエラー、メタデータ破損、デバイス切断、RAID劣化、ストレージ遅延などが潜んでいることが多いからです。

現場の「心の会話」— その焦りは自然です

「今日だけは書けてほしいんだけど…」

「監視に怒られてるし、上には“原因は？”って聞かれるし…」

こう感じるのは自然ですし、むしろ健全な危機感です。ただ、ここで“動かしてしまう”と、あとで説明がもっと難しくなることがあります。なぜなら、障害が進行すると「いつから壊れたのか」「何がトリガーか」「どの書き込みで決定的に壊れたか」が曖昧になり、復旧戦略（修復か移行か、バックアップ復元か、データ救出か）の判断材料が減るからです。

最初の5分でやること：被害最小化のための観測点をそろえる

まずは“書き込みを増やさずに”状況を掴みます。rootがroになっているとログが残せないこともあるので、画面コピーや別ホストへの転送も含めて、観測結果を確保します。

  • mount または findmnt -T / で対象が ro か確認
  • df -h / df -i で容量・inode逼迫の有無を確認（別原因の混入を排除）
  • dmesg -T | tail でI/Oエラーやファイルシステム警告を確認
  • CentOS 7/8系なら journalctl -k -b（カーネルログ）を確認

この段階で「I/O error」「EXT4-fs error」「XFS: metadata I/O error」「Buffer I/O error」「blk_update_request」などが出ていれば、“ro化は防波堤”である可能性が高いです。逆に、ログが静かでも、下位層（RAID/HBA/仮想基盤/ストレージ）のイベントにヒントがあることもあります。

この章の要点

  • EROFSは“アプリの問題”ではなく“OSが危険を察知した結果”であることが多い
  • 焦って動かすほど、原因追跡と復旧判断の材料が減り、収束しにくくなる
  • 最初の5分は「観測」と「被害最小化」を優先する

　

第2章：EROFS(30)は“原因”ではなく“保護動作” — まず症状を正しく読む

「EROFS 30」は、Linuxのエラー番号でいうと Read-only file system を意味します。ポイントは、“ディスクが読み取り専用の製品（CD-ROM等）だった”という話ではなく、その時点でカーネルが対象ファイルシステムをroとして扱っている、という状態の表現だということです。

代表的な発生パターン：カーネルが自動的に remount-ro する

ext4など一部のファイルシステムは、重大なメタデータ不整合やI/Oエラーを検知すると、これ以上の破壊を防ぐために自動的に読み取り専用へ切り替える挙動があります（いわゆる errors=remount-ro の系統）。XFSの場合も、深刻なエラー時に“shutdown”状態となり、結果として書き込みができなくなります。いずれも狙いは同じで、壊れた状態で書き込みを継続し、整合性をさらに崩すことを避けるためです。

つまり、EROFSが見えた時点で「既に何かが起きている」可能性が高い。ここを見誤ると、復旧の優先順位がズレます。

「再マウントすれば直る？」への現実的な答え

再マウント（mount -o remount,rw）で一時的に書けるようになるケースはあります。ただし、それは“根本原因が解決した”ことを意味しません。たとえば一瞬だけI/Oが戻った、瞬断が解消した、負荷が下がった、といった偶然の上で動いている場合があります。

現場目線で言うと、ここが一番の分岐点です。

「書けるようになった。よし、デプロイ再開！」

この判断が危ないのは、再びエラーが起きた瞬間に、今度はDBやアプリの更新途中で落ち、状態が中途半端になるからです。結果として、障害対応は“ファイルシステム”だけでなく“アプリ整合性”まで巻き込む形になり、説明と復旧が難しくなります。

観測の読み方：エラーの層を分ける

EROFSに至る道筋は複数あります。原因を見誤らないために、症状を「層」で整理します。

層 代表的な観測点 典型例
アプリ層 ログ、例外、再起動ループ ログ書き込み失敗、PID作成失敗
OS/FS層 mount状態、dmesg、journalctl -k EXT4/XFSのエラー、remount-ro
ブロック層 I/O error、reset、timeout SATAリンクリセット、SCSI timeout
ストレージ/基盤層 RAID劣化、パス切替、SANイベント 冗長切替、キャッシュ電池劣化、瞬断

この表のどこに根っこがあるかで、次の一手が変わります。アプリだけ見て「権限の問題だ」と決め打ちすると、下位層の故障を見逃します。逆に、下位層だけ見て「ディスク交換だ」と決め打ちすると、ファイルシステム修復やアプリ整合性の手当てが後回しになります。

この章の要点

  • EROFS(30)は“原因名”ではなく“カーネルがro扱いにした状態”の表現
  • 再マウントで一時回復しても、根本原因が解決したとは限らない
  • アプリ→OS/FS→ブロック→基盤の層で観測し、判断のブレーキをかける

　

第3章：現場でやりがちなNG集 — 再起動・強制rw・連打が悪化させる理由

ここは耳が痛い話をします。現場は忙しいし、監視は鳴るし、上からは状況確認が飛んでくる。だから“早く戻す”行動を取りたくなる。でも、EROFSのときにやりがちな行動の一部は、結果として損失・流出（ログや証跡の喪失、データ不整合の増加）につながります。

NG1：何も見ずに再起動（証拠が消える・状態が変わる）

再起動は、状況を変えます。場合によっては一時的に直ったように見える。しかし同時に、切り分けの材料も失われます。

  • メモリ上の状態（キャッシュ、未同期の書き込み）が失われ、再現条件が曖昧になる
  • 起動時のfsckやリプレイで状態が変わり、“何が悪かったか”が見えにくくなる
  • ログがディスクに書けない状態だと、そもそも障害直前のログが残っていないことがある

特にrootがroになっていると、ログ出力先が詰まり、アプリが異常終了したり、監視が誤検知を増やしたりします。だからこそ“再起動したい”気持ちは分かるのですが、先にやるべきは観測と保全です。

NG2：強引なremount,rw連打（壊れた前提で書く危険）

「とりあえず mount -o remount,rw / で戻す」──これは成功体験があるほど危険です。下位層でI/Oが不安定なまま書き込みを再開すると、メタデータ破損が進行し、修復が難しくなります。ext4ならジャーナルやメタデータに追加の不整合が乗る可能性があり、XFSなら障害モードのまま無理に触って状況が悪化することがあります。

ここでの考え方はシンプルです。“壊れた可能性がある場所に、さらに書く”のは、復旧を難しくする方向に働きやすい。だからまずは、書き込みを止める／最小化する方針に寄せます。

NG3：原因が分からないままアプリだけ復旧（整合性の負債が残る）

一時的に書けたのでアプリを再起動、デプロイ再実行、DBマイグレーション再実行……この流れは、後で“説明不能な違和感”として返ってきます。たとえば、あるテーブルだけ更新が中途半端、ログは欠落、設定反映は途中、キューの再処理で二重実行、といった具合です。

「なんか直ったけど、気持ち悪い」状態は、障害対応のダメージコントロールとしては失格になりがちです。なぜなら“次の障害”の種を埋め込みやすいからです。

じゃあ何をする？：やることを“少なく”するのが正解な場面

EROFSでまず大事なのは、作業を増やすことではなく、作業を絞ることです。最初の方針は次の3つに集約できます。

  1. 書き込みを増やさない（サービス停止/メンテナンスモード/キュー停止など）
  2. 観測点を確保する（dmesg/journalctl/RAIDログ/SMARTなど）
  3. 復旧方針を決める（修復・移行・復元・データ救出のどれを採るか）

この時点で「ディスクが怪しい」「RAIDがDegraded」「仮想基盤でストレージ瞬断があった」などの兆候があるなら、一般論で押し切るより、個別環境に合わせた判断が必要です。たとえば、DBの種類や冗長構成、ストレージの種類（ローカル/ネットワーク/クラウド）、バックアップ世代、停止できる時間で、最適解は変わります。

この章の要点

  • 再起動は“状況を変える”ので、先に観測と保全を
  • remount,rwの連打は、復旧難度を上げる方向に働きやすい
  • アプリ復旧を急ぐほど、整合性の負債が残りやすい

　

第4章：最優先はデータ保全 — 「書き込み停止」と影響範囲の切り分け判断

EROFSが出ているとき、現場が最初にやるべきは「復旧」ではなく「保全」です。ここで言う保全は、法務的な証拠保全というより、技術的に“これ以上壊さない”ための行動です。読み取り専用化はOSが勝手に歯止めをかけてくれている状態でもあります。ならば人間側も、同じ方向に寄せた方が結果的に収束が早いことが多いです。

「書き込み停止」を現実的にやる：止める範囲を決める

書き込み停止と言っても、システム全停止が必須とは限りません。重要なのは「壊れた可能性のある領域への追加書き込み」を減らすことです。たとえば、次のように“段階”で考えられます。

段階 狙い 例
軽度 追加書き込みの発生源を抑える バッチ停止、キュー停止、ログ出力先変更（別ディスク/別ホスト）
中度 影響の大きいサービスだけ止める DB停止、書き込みAPI停止、メンテナンスモード
重度 ホスト全体の状態を固定化する システム停止、スナップショット取得、別ホストへフェイルオーバー

ポイントは、やみくもに止めるのではなく「どの書き込みが継続すると被害が増えるか」を見極めることです。たとえば、DBが載っているボリュームがroになった場合、DBを動かし続けるのは整合性面で極めて危険です。一方で、読み取り専用の静的コンテンツだけなら、読み取り提供は継続できることもあります。

影響範囲の切り分け：どのマウントポイントがroか

「/ がro」なのか、「/var だけがro」なのか、「/data（LVMや別ディスク）がro」なのかで、対応は大きく変わります。まずは対象を明確にします。

  • findmnt でマウントポイントとオプション（ro/rw）を確認
  • lsblk -f でデバイスとファイルシステム種別、UUIDを確認
  • lvs / vgs / pvs でLVM配下かどうか確認（利用している場合）

この段階で「複数ボリュームが同時にro」なら、ストレージ基盤側の問題（瞬断、I/Oタイムアウト、RAID劣化）が疑わしいです。逆に「特定ボリュームだけro」なら、そのボリュームのファイルシステム破損や該当ディスク不良の可能性が上がります。

保全の現実：ログが残らないなら“外に出す”

rootや/varがroになっていると、ログが書けず、診断の材料が欠けます。ここで“OSの中に残す”発想を捨てて、外に出します。

  • 画面出力の保存（作業端末にコピー）
  • 別ホストへ転送（scp/rsyncが可能なら、読み取りのみでログを吸い出す）
  • 監視基盤やストレージ管理画面のイベント履歴も同時に保存

「そんなことしてる暇ない」と思いがちですが、後から“説明”が必要になるのが障害対応です。現場の負担を下げるためにも、初動で材料を確保するのは最終的に効きます。

この章の要点

  • EROFSの初動は復旧より保全。OSの歯止めに合わせて作業を絞る
  • 止める範囲は段階で判断（軽度〜重度）
  • 影響範囲（どのマウントがroか）を明確にし、ログは外へ出す

　

第5章：応急処置の手順 — remountの正しい使い方と「一時復帰」の落とし穴

ここから先は“応急処置”の話です。重要なのは、応急処置は「その場を整える」ための手段であり、根本解決ではないという前提です。応急処置を根本解決と勘違いすると、あとで大きな反動が来ます。

remountの前に：本当にrwに戻してよい状況か

再マウントでrwに戻す判断は、状況依存です。一般に、次のような兆候がある場合は、まずrw化を急がず、原因追跡と保全を優先した方が安全です。

  • カーネルログにI/Oエラー、タイムアウト、リセットが出ている
  • RAIDがDegraded、またはパトロールリード/リビルド中
  • SMARTで再配置セクタ増加など、ディスク劣化の兆候がある
  • 仮想基盤・SAN側で瞬断やパス切替のイベントがある

逆に、原因が明確に“運用上の設定ミス”や“一時的な条件”で、下位層が健全である確度が高い場合（例：誤ってroオプションでマウントしていた、読み取り専用のコンテナイメージ上で書こうとしていた、など）は、手順を踏めばrw化が妥当なケースもあります。ただし、今回のテーマは「突然のRead-only file system」なので、基本線は慎重側です。

応急処置の狙いを分ける：目的は2つしかない

応急処置の目的は、だいたい次の2つに収束します。

  1. 必要最小限の書き込みを可能にして、退避・収束作業を進める（例：設定を切り替えて別ストレージへ逃がす）
  2. サービスを“読むだけ”に落とし、致命的な不整合を避ける（例：書き込みAPI停止）

「元通りに戻して通常運転」ではありません。ここを目標にすると、短期的に回っても中期的に再発して炎上しやすいです。

remountの基本：対象とオプションを誤らない

再マウントは対象マウントポイントを間違えると、期待した効果が出ません。まずは対象を確定します。

  • findmnt -T /対象パス で、そのパスがどのマウント配下かを確認
  • mount | grep ' on /対象 ' で現状のオプションを確認

そのうえで、たとえば対象が /data なら次のように実行します。

  • mount -o remount,rw /data

ただし、これで書けるようになったとしても、それは“今この瞬間だけ”かもしれません。書き込み再開の前に、最低限の健全性確認（ログの追加観測、下位層イベント確認）を入れるのが現実的です。

「一時復帰」の落とし穴：書けた瞬間にやってはいけないこと

一時的にrw化できた瞬間、現場は“全部戻したく”なります。そこで次の行動をすると、状況が悪化しやすいです。

  • DBマイグレーションや大規模バッチを再開する（書き込み量が多い）
  • ログローテーションや圧縮など、大量のメタデータ更新を走らせる
  • パッケージ更新（rpm/yum/dnf）を行う（途中失敗すると整合性問題を呼びやすい）

応急処置でrw化できたなら、まずは“退避”と“収束”に使うのが安全です。例えば、必要なログや設定、DBダンプの退避（ただし書き込み先は別ストレージや別ホスト）などです。ここで無理をすると、再度ro化したときに、今度は作業途中の不整合も抱えます。

応急処置の代替：rwに戻さずに回避する選択肢

状況によっては、rwに戻すより“運用を切り替える”方が安全です。

  • ログ出力先を外部へ（syslog転送、別ボリューム）
  • 一時ディレクトリをtmpfsに（ただしメモリ枯渇に注意）
  • 書き込みAPIを止め、読み取り提供のみ継続

これらは「壊れた可能性のあるストレージに書かない」方向の設計で、障害の抑え込みに効きます。

この章の要点

  • remountは“応急処置”であり、根本原因の解消ではない
  • rw化できても、すぐ通常運転に戻さず、退避と収束に使う
  • 状況次第では、rw化せず運用切替（外部ログ、読み取り専用運用）が安全

　

第6章：なぜ読み取り専用になるのか — ext4/XFSとI/Oエラーの連鎖を理解する

「Read-only file system」になった瞬間、現場は“ファイルシステムが壊れた”と考えがちです。半分は当たりで、半分は外れです。というのも、読み取り専用化はファイルシステム自身の破損だけでなく、下位層のI/O異常（ディスク、コントローラ、ケーブル、SAN、仮想基盤、電源・冷却など）を検知した結果として起きることが多いからです。つまり、EROFSは「最終的にOSが出した結論」で、根本原因は別の層にいる可能性があります。

ext4でよくある流れ：エラー検知 → remount-ro

ext4は、メタデータ更新やジャーナリングの過程で重大な不整合やI/Oエラーを検知すると、これ以上の書き込みを続けないために読み取り専用へ切り替えることがあります。カーネルログには、一般に次のような系統のメッセージが出ることが多いです（文言は環境やバージョンで前後します）。

  • EXT4-fs error / EXT4-fs (device …): error count since last fsck
  • Aborting journal / Journal has aborted
  • Remounting filesystem read-only

ここで重要なのは、ext4が「壊れた可能性が高いから、これ以上書かない」と判断している点です。無理にrwに戻すと、“壊れた可能性がある前提”でメタデータ更新を続行することになり、結果的に修復が難しくなる方向へ進むことがあります。

XFSでよくある流れ：メタデータI/O異常 → shutdown（実質的に書けない）

CentOS系ではデータ領域にXFSを採用しているケースも多いですが、XFSは重大なメタデータI/Oエラーなどを検知するとファイルシステムを“shutdown”状態にすることがあります。この状態になると、書き込みは失敗し続け、アプリから見るとEROFS相当の挙動になります。ログには次のような系統が出ることが多いです。

  • XFS (…): metadata I/O error
  • XFS (…): Log I/O Error Detected
  • XFS (…): Corruption detected. Unmount and run xfs_repair

XFSでは、修復に xfs_repair を使うことが多い一方で、原則として対象をアンマウントした状態で実施する必要があります。稼働中に「とりあえず修復」をやりたくなる気持ちは分かりますが、ここは慎重に手順を組む局面です。

ファイルシステムが悪いとは限らない：I/Oエラーの“連鎖”

読み取り専用化の背後に、実はブロック層のI/O異常がいることは珍しくありません。たとえば、ディスクの不良セクタ、SSDの劣化、コントローラのタイムアウト、ケーブル接触不良、SANのパス切替、仮想基盤でのストレージ瞬断などです。こうした異常が起きると、ファイルシステムは「正しく書けたか保証できない」状態になり、結果として安全側に倒れます。

現場の“心の会話”で言うとこうです。

「ファイルシステム直せば終わりでしょ？」

実際には、直してもまた起きるなら、下位層が原因である可能性が高い。だから、EROFSを見たときは「FS修復だけで終わらない前提」で観測点を揃えるのが、結果的に被害最小化につながります。

この章の要点

  • ext4は重大エラー時に remount-ro しやすく、XFSは shutdown 状態で実質的に書けなくなることがある
  • EROFSの裏にI/O異常（ディスク/RAID/SAN/仮想基盤など）がいることが多い
  • 「FSだけ直す」ではなく、下位層まで含めて原因を追うのが収束を早める

　

第7章：根本診断の定石 — dmesg/journalctl/SMART/RAID/LVMで“裏側”を掘る

ここからは、原因に近づくための“定石”です。ポイントは、ログを闇雲に眺めるのではなく、層を意識して順番に掘ることです。EROFSは結果なので、結果から逆算して「どの層で破綻した可能性が高いか」を当てにいきます。

診断の順番：OS/FS → ブロック → ストレージ/基盤

まずはOSとファイルシステムのログから入るのが現実的です。CentOSでは次が入口になります。

  • カーネルリングバッファ：dmesg -T
  • systemd採用環境：journalctl -k -b（カーネルログ、当該ブート）
  • 従来ログ：/var/log/messages（ただしroで更新されないことがある）

見つけたいのは「ファイルシステムの警告」だけではなく、より下の層の兆候です。たとえば次のような“匂い”があると、ディスク/パス/コントローラ側が怪しくなります。

  • Buffer I/O error
  • blk_update_request: I/O error
  • reset / timeout / link is down（SATA/SCSI系のタイムアウトやリセット）
  • device-mapper / multipath のパス切替ログ

観測ポイントを表で整理する：何を見て、何が分かるか

対象 コマンド例 見たいポイント
マウント状態 findmnt / mount ro/rw、対象マウントポイントの特定
FS種別 lsblk -f / blkid ext4/XFS、UUID、デバイス対応
カーネルログ dmesg -T / journalctl -k -b I/O error、FS error、timeout、reset
ディスク健全性 smartctl -a /dev/sdX（smartmontools） SMART異常、再配置、エラー履歴（※取得可否は機種依存）
ソフトRAID(md) cat /proc/mdstat / mdadm --detail Degraded、リビルド中、失敗ディスク
LVM pvs/vgs/lvs PV欠損、VG状態、LVの所在

ハードRAID（HBA/RAIDカード）を使っている場合は、ベンダーや機種で確認手段が変わります（例：storcli/megacli等）。ここは環境差が大きいので、運用で使っている標準手順（監視画面、管理CLI、ベンダーツール）に沿って“劣化・パトロールリード・キャッシュ保護・バッテリ状態”などを確認します。

fsck / xfs_repair の前に押さえるべき注意点

ファイルシステム修復は強力ですが、前提条件を誤ると状況を変えてしまいます。一般に次の考え方が安全側です。

  • 修復は原則としてアンマウント状態で行う（稼働中に無理をしない）
  • 下位層が不安定（I/O errorやタイムアウト継続）のまま修復しても、再発しやすい
  • 「まず直す」より「原因が継続していないか」を確認してから直す方が収束しやすい

現場では「今すぐ直して復帰」が求められますが、下位層の異常が続いているなら、修復してもすぐ同じ症状に戻り、結果として対応コストが増えます。ここで一度、判断のブレーキを踏んで、ログと状態を根拠に方針を選ぶのが大事です。

この章の要点

  • 層（OS/FS→ブロック→基盤）を意識して、ログと状態を揃える
  • dmesg/journalctlでI/Oエラー系の兆候を拾い、SMART/RAID/LVMで裏取りする
  • 修復は強力だが、前提（アンマウント、下位層の安定）を誤ると収束しにくい

　

第6章：なぜ読み取り専用になるのか — ext4/XFSとI/Oエラーの連鎖を理解する

「Read-only file system」になった瞬間、現場は“ファイルシステムが壊れた”と考えがちです。半分は当たりで、半分は外れです。というのも、読み取り専用化はファイルシステム自身の破損だけでなく、下位層のI/O異常（ディスク、コントローラ、ケーブル、SAN、仮想基盤、電源・冷却など）を検知した結果として起きることが多いからです。つまり、EROFSは「最終的にOSが出した結論」で、根本原因は別の層にいる可能性があります。

ext4でよくある流れ：エラー検知 → remount-ro

ext4は、メタデータ更新やジャーナリングの過程で重大な不整合やI/Oエラーを検知すると、これ以上の書き込みを続けないために読み取り専用へ切り替えることがあります。カーネルログには、一般に次のような系統のメッセージが出ることが多いです（文言は環境やバージョンで前後します）。

  • EXT4-fs error / EXT4-fs (device …): error count since last fsck
  • Aborting journal / Journal has aborted
  • Remounting filesystem read-only

ここで重要なのは、ext4が「壊れた可能性が高いから、これ以上書かない」と判断している点です。無理にrwに戻すと、“壊れた可能性がある前提”でメタデータ更新を続行することになり、結果的に修復が難しくなる方向へ進むことがあります。

XFSでよくある流れ：メタデータI/O異常 → shutdown（実質的に書けない）

CentOS系ではデータ領域にXFSを採用しているケースも多いですが、XFSは重大なメタデータI/Oエラーなどを検知するとファイルシステムを“shutdown”状態にすることがあります。この状態になると、書き込みは失敗し続け、アプリから見るとEROFS相当の挙動になります。ログには次のような系統が出ることが多いです。

  • XFS (…): metadata I/O error
  • XFS (…): Log I/O Error Detected
  • XFS (…): Corruption detected. Unmount and run xfs_repair

XFSでは、修復に xfs_repair を使うことが多い一方で、原則として対象をアンマウントした状態で実施する必要があります。稼働中に「とりあえず修復」をやりたくなる気持ちは分かりますが、ここは慎重に手順を組む局面です。

ファイルシステムが悪いとは限らない：I/Oエラーの“連鎖”

読み取り専用化の背後に、実はブロック層のI/O異常がいることは珍しくありません。たとえば、ディスクの不良セクタ、SSDの劣化、コントローラのタイムアウト、ケーブル接触不良、SANのパス切替、仮想基盤でのストレージ瞬断などです。こうした異常が起きると、ファイルシステムは「正しく書けたか保証できない」状態になり、結果として安全側に倒れます。

現場の“心の会話”で言うとこうです。

「ファイルシステム直せば終わりでしょ？」

実際には、直してもまた起きるなら、下位層が原因である可能性が高い。だから、EROFSを見たときは「FS修復だけで終わらない前提」で観測点を揃えるのが、結果的に被害最小化につながります。

この章の要点

  • ext4は重大エラー時に remount-ro しやすく、XFSは shutdown 状態で実質的に書けなくなることがある
  • EROFSの裏にI/O異常（ディスク/RAID/SAN/仮想基盤など）がいることが多い
  • 「FSだけ直す」ではなく、下位層まで含めて原因を追うのが収束を早める

　

第7章：根本診断の定石 — dmesg/journalctl/SMART/RAID/LVMで“裏側”を掘る

ここからは、原因に近づくための“定石”です。ポイントは、ログを闇雲に眺めるのではなく、層を意識して順番に掘ることです。EROFSは結果なので、結果から逆算して「どの層で破綻した可能性が高いか」を当てにいきます。

診断の順番：OS/FS → ブロック → ストレージ/基盤

まずはOSとファイルシステムのログから入るのが現実的です。CentOSでは次が入口になります。

  • カーネルリングバッファ：dmesg -T
  • systemd採用環境：journalctl -k -b（カーネルログ、当該ブート）
  • 従来ログ：/var/log/messages（ただしroで更新されないことがある）

見つけたいのは「ファイルシステムの警告」だけではなく、より下の層の兆候です。たとえば次のような“匂い”があると、ディスク/パス/コントローラ側が怪しくなります。

  • Buffer I/O error
  • blk_update_request: I/O error
  • reset / timeout / link is down（SATA/SCSI系のタイムアウトやリセット）
  • device-mapper / multipath のパス切替ログ

観測ポイントを表で整理する：何を見て、何が分かるか

対象 コマンド例 見たいポイント
マウント状態 findmnt / mount ro/rw、対象マウントポイントの特定
FS種別 lsblk -f / blkid ext4/XFS、UUID、デバイス対応
カーネルログ dmesg -T / journalctl -k -b I/O error、FS error、timeout、reset
ディスク健全性 smartctl -a /dev/sdX（smartmontools） SMART異常、再配置、エラー履歴（※取得可否は機種依存）
ソフトRAID(md) cat /proc/mdstat / mdadm --detail Degraded、リビルド中、失敗ディスク
LVM pvs/vgs/lvs PV欠損、VG状態、LVの所在

ハードRAID（HBA/RAIDカード）を使っている場合は、ベンダーや機種で確認手段が変わります（例：storcli/megacli等）。ここは環境差が大きいので、運用で使っている標準手順（監視画面、管理CLI、ベンダーツール）に沿って“劣化・パトロールリード・キャッシュ保護・バッテリ状態”などを確認します。

fsck / xfs_repair の前に押さえるべき注意点

ファイルシステム修復は強力ですが、前提条件を誤ると状況を変えてしまいます。一般に次の考え方が安全側です。

  • 修復は原則としてアンマウント状態で行う（稼働中に無理をしない）
  • 下位層が不安定（I/O errorやタイムアウト継続）のまま修復しても、再発しやすい
  • 「まず直す」より「原因が継続していないか」を確認してから直す方が収束しやすい

現場では「今すぐ直して復帰」が求められますが、下位層の異常が続いているなら、修復してもすぐ同じ症状に戻り、結果として対応コストが増えます。ここで一度、判断のブレーキを踏んで、ログと状態を根拠に方針を選ぶのが大事です。

この章の要点

  • 層（OS/FS→ブロック→基盤）を意識して、ログと状態を揃える
  • dmesg/journalctlでI/Oエラー系の兆候を拾い、SMART/RAID/LVMで裏取りする
  • 修復は強力だが、前提（アンマウント、下位層の安定）を誤ると収束しにくい

はじめに


CentOSを運用する企業やシステム管理者にとって、突然の「Read-only file system」（読み取り専用ファイルシステム）エラーは深刻なトラブルの一つです。このエラーは、システムの安定性やデータの安全性に直結し、適切な対応を取らなければ業務に大きな影響を及ぼす可能性があります。特に、EROFS（Enhanced Read-Only File System）と呼ばれる読み取り専用のファイルシステムが導入されている環境では、原因の特定や対応方法が複雑になることもあります。 本記事では、このエラーが発生した際に取るべき基本的な対策や、再マウントの手順、設定変更のポイントについて解説します。システムの安定運用を維持し、万が一の事態に備えるためには、正しい知識と冷静な対応が不可欠です。 また、データ復旧の専門家としての視点から、迅速かつ安全に問題を解決するためのアドバイスも併せてご紹介します。システム管理者の皆さまが安心して対応できるよう、現場で役立つ情報をわかりやすくお伝えします。



読み取り専用ファイルシステムの原因と定義について理解することは、適切な対策を講じるための第一歩です。一般に、ファイルシステムが読み取り専用に切り替わるのは、システムの安定性やデータの保護を目的とした緊急対応の一環です。たとえば、ハードウェアの故障や不具合、電源の不安定さ、またはファイルシステムの破損が原因となることが多くあります。特に、EROFS（Enhanced Read-Only File System）を採用している環境では、システムの安全性を確保するために、異常を検知した際に自動的に書き込みを停止し、データの損失やさらなる破損を防ぐ措置が取られることがあります。 この状態は、システムの予期せぬエラーや不具合に対して、迅速に対応するための安全策です。しかしながら、システム管理者やIT担当者にとっては、業務の継続やデータの復旧を優先しなければならない場面も多く、原因の特定と解決策の実施が求められます。ファイルシステムが読み取り専用に切り替わる背景には、ハードウェアの障害だけでなく、ソフトウェアのバグや設定ミスも関与していることがあります。 したがって、まずはシステムのログやエラーメッセージを確認し、どのような原因で読み取り専用状態になったのかを理解することが重要です。これにより、再マウントや設定変更の際に適切な対応策を選択できるようになります。システムの安定性を確保しつつ、データの安全性を守るためにも、正確な原因把握と適切な対応が必要です。 ※当社は、細心の注意を払って当社ウェブサイトに情報を掲載しておりますが、この情報の正確性および完全性を保証するものではありません。当社は予告なしに、当社ウェブサイトに掲載されている情報を変更することがあります。当社およびその関連会社は、お客さまが当社ウェブサイトに含まれる情報もしくは内容をご利用されたことで直接・間接的に生じた損失に関し一切責任を負うものではありません。



詳細な原因の特定と対応策について理解を深めることは、システムの安定運用に不可欠です。読み取り専用状態になる原因は多岐にわたりますが、具体的にはハードウェアの故障やディスクの物理的な損傷、ファイルシステムの破損、または不適切なシャットダウンによる一時的な異常などが挙げられます。特に、EROFSを採用している環境では、システムが異常を検知した際に自動的に書き込みを停止し、データの保護を優先する仕組みが働きます。 例えば、ディスクの不良セクタや電源の不安定さが原因の場合、システムログやエラーメッセージに具体的な情報が記録されていることが多いです。これらの情報をもとに、原因の特定と適切な対応を行う必要があります。ハードウェアの故障であれば、ディスクの交換や修理、ソフトウェアの不具合であれば、ファイルシステムの修復や設定の見直しが必要です。 また、システムが読み取り専用に切り替わった際に最も重要なのは、データのバックアップと復旧計画の確立です。万が一のデータ損失を最小限に抑えるために、定期的なバックアップを行い、迅速に復旧できる体制を整えておくことが望ましいです。さらに、システムのログや監視ツールを活用し、異常の兆候を早期に察知することも重要です。 原因の解明と対策には専門的な知識が必要な場合もあります。そのため、信頼できるデータ復旧の専門業者やシステムエンジニアと連携し、適切な対応を取ることが、システムの安定とデータの安全を守るためのポイントです。現状のシステム状態を正確に把握し、迅速かつ確実な対応を進めることが、トラブルの拡大を防ぐ最善の策となります。 ※当社は、細心の注意を払って当社ウェブサイトに情報を掲載しておりますが、この情報の正確性および完全性を保証するものではありません。当社は予告なしに、当社ウェブサイトに掲載されている情報を変更することがあります。当社およびその関連会社は、お客さまが当社ウェブサイトに含まれる情報もしくは内容をご利用されたことで直接・間接的に生じた損失に関し一切責任を負うものではありません。



システムの安定性を維持しながら読み取り専用状態を解除するためには、適切な対応策を段階的に実施することが重要です。まず、システムのログやエラーメッセージを詳細に確認し、原因を特定します。例えば、ディスクの不良やファイルシステムの破損が疑われる場合は、ファイルシステムの修復ツールを使用して修復を試みることが一般的です。ただし、これらの作業は慎重に行う必要があり、事前にデータのバックアップを取ることが推奨されます。 次に、原因の特定に基づき、ハードウェアの点検や修理を行います。ディスクの不良セクタや電源の不安定さが原因の場合、ハードウェアの交換や修理を検討します。ソフトウェア的な問題の場合は、設定の見直しやファイルシステムの再構築を行うことが効果的です。 また、再マウントのためには、まずシステムを一旦安全な状態に停止させる必要があります。その後、マウントコマンドを用いて読み取り書き込み可能な状態に切り替えますが、その前にシステムの整合性を確認することが不可欠です。たとえば、`mount -o remount,rw /`コマンドを使うことで、ルートファイルシステムを再マウントできます。ただし、これらの操作はシステムの状態や原因によって異なるため、状況に応じた適切なコマンド選択と実行が求められます。 最後に、設定変更や再マウント後も、システムの動作を継続的に監視し、異常が再発しないか確認します。必要に応じて、システム監視ツールやアラート設定を活用し、早期に異常を検知できる体制を整えることも重要です。これらの対応を適切に行うことで、システムの安定性とデータの安全性を確保しながら、トラブルの再発を防ぐことが可能となります。 ※当社は、細心の注意を払って当社ウェブサイトに情報を掲載しておりますが、この情報の正確性および完全性を保証するものではありません。当社は予告なしに、当社ウェブサイトに掲載されている情報を変更することがあります。当社およびその関連会社は、お客さまが当社ウェブサイトに含まれる情報もしくは内容をご利用されたことで直接・間接的に生じた損失に関し一切責任を負うものではありません。



読み取り専用ファイルシステムの状態から正常な書き込み可能な状態に戻すためには、適切な対応策を段階的に実施することが重要です。まず、原因の特定とともに、システムのログやエラーメッセージを詳細に確認し、どのような事象がシステムを読み取り専用に切り替えさせたのかを把握します。ハードウェアの故障やファイルシステムの破損が原因の場合は、修復ツールやコマンドを用いて修復を試みる必要があります。ただし、これらの操作はデータの損失を防ぐために事前のバックアップが不可欠です。 次に、原因に応じた対応を行います。ハードウェアの不具合が原因であれば、ディスクの交換や修理を検討します。ソフトウェア側の問題であれば、設定の見直しやファイルシステムの再構築を行います。再マウントの操作は、システムを一旦安全な状態に停止させた後、`mount -o remount,rw /`コマンドなどを用いて行います。ただし、システムの状態や原因によって操作方法は異なるため、慎重に実施しなければなりません。 また、再マウント後もシステムの動作を継続的に監視し、異常が再発しないかを確認します。システム監視ツールやアラート設定を活用し、異常兆候を早期に察知できる体制を整えることも推奨されます。これらの対応を適切に行うことで、システムの安定性とデータの安全性を確保しつつ、トラブルの再発を防ぐことが可能となります。 万が一、対応に不安がある場合や原因の特定が難しい場合は、信頼できるデータ復旧やシステム修復の専門業者に相談することも選択肢の一つです。正確な診断と適切な対応によって、システムの正常な運用を早期に回復できるようサポートします。 ※当社は、細心の注意を払って当社ウェブサイトに情報を掲載しておりますが、この情報の正確性および完全性を保証するものではありません。当社は予告なしに、当社ウェブサイトに掲載されている情報を変更することがあります。当社およびその関連会社は、お客さまが当社ウェブサイトに含まれる情報もしくは内容をご利用されたことで直接・間接的に生じた損失に関し一切責任を負うものではありません。



読み取り専用ファイルシステムの状態から正常な書き込み可能な状態に戻すには、原因の特定と適切な対応策の実施が不可欠です。まず、システムのログやエラーメッセージを詳細に確認し、どの事象がシステムを読み取り専用に切り替えさせたのかを把握します。原因としてはハードウェア障害、ディスクの不良セクタ、ファイルシステムの破損、または不適切なシャットダウンなどが考えられます。 次に、原因に応じた対応策を段階的に行います。ハードウェアの不具合が疑われる場合は、ディスクの修理や交換を検討し、ソフトウェアの問題であれば、ファイルシステムの修復や設定の見直しを行います。再マウントの操作は、システムを一旦安全な状態に停止させた上で、`mount -o remount,rw /`コマンドなどを用いて実施します。ただし、操作前に必ずデータのバックアップを取ることが重要です。 また、再マウント後もシステムの動作監視を継続し、異常の再発を防ぐために監視ツールやアラート設定を活用します。これにより、早期に異常を察知し適切な対応を取ることが可能となります。もし対応に不安や疑問がある場合は、信頼できる専門業者に相談し、正確な診断と安全な修復を依頼することも選択肢です。こうした継続的な管理と適切な対応によって、システムの安定性とデータの安全性を守ることができ、トラブルの再発を未然に防ぐことにつながります。 ※当社は、細心の注意を払って当社ウェブサイトに情報を掲載しておりますが、この情報の正確性および完全性を保証するものではありません。当社は予告なしに、当社ウェブサイトに掲載されている情報を変更することがあります。当社およびその関連会社は、お客さまが当社ウェブサイトに含まれる情報もしくは内容をご利用されたことで直接・間接的に生じた損失に関し一切責任を負うものではありません。



システムの安定運用において、読み取り専用ファイルシステムのエラーは避けて通れない課題です。原因の特定と適切な対応策を実行することが、データの安全性とシステムの信頼性を維持するための基本となります。ハードウェアの故障やファイルシステムの破損、ソフトウェアの設定ミスなど、多岐にわたる原因に対して、冷静かつ正確な判断と対応が求められます。 具体的には、原因の把握、データのバックアップ、修復作業や設定変更、そして再マウントの手順を段階的に進めることが重要です。これらの作業は、専門的な知識や経験を持つ技術者や信頼できる業者と連携しながら行うことで、リスクを最小限に抑えながら解決へと導くことができます。 また、システムの監視と定期的なメンテナンスも、トラブルの早期発見と未然防止に役立ちます。万一の事態に備え、事前の準備と対応策を整えておくことが、システムの継続的な安定性とデータの安全確保に繋がります。適切な知識と冷静な判断を持ち、必要に応じて専門家の支援を仰ぐことが、トラブルを最小限に抑える最良の方法です。



システムの安定運用とデータの安全確保には、適切な知識と迅速な対応が欠かせません。もし、読み取り専用ファイルシステムのエラーに直面した場合は、焦らず冷静に状況を把握し、必要に応じて専門の技術者や信頼できるデータ復旧業者に相談することをお勧めします。早めの対応がトラブルの拡大を防ぎ、システムの信頼性を維持する鍵となります。私たちは、万が一の事態に備えたサポート体制を整え、安心してシステム運用を続けていただくためのアドバイスや支援を提供しています。お困りの際には、遠慮なくご相談ください。適切な対応策と専門的な支援によって、システムの安定とデータの安全を守るお手伝いをさせていただきます。



システムの読み取り専用ファイルシステムのエラー対応においては、いくつかの重要なポイントに注意が必要です。まず、原因の特定と対応策の実施にあたっては、事前に十分なバックアップを行うことが不可欠です。これにより、万が一修復作業中にデータ損失やさらなる障害が発生した場合でも、復旧の選択肢を確保できます。また、操作を行う際には、システムの状態や原因を正確に把握し、適切なコマンドや手順を選択することが求められます。誤った操作は、システムの安定性を損ねたり、データの破損を招く可能性があります。 さらに、自己判断で修復作業を行う前に、専門知識を持つ技術者や信頼できる業者に相談することが望ましいです。特に、ハードウェアの故障やファイルシステムの深刻な破損が疑われる場合は、専門的な診断と修復が必要となるため、安易な対応は避けるべきです。また、再マウントや設定変更の操作は、システムの稼働状況や原因に応じて適切に行わなければ、再発やシステムダウンのリスクを高めることになります。 最後に、対応後もシステムの動作監視を継続し、異常兆候を早期に察知できる体制を整えることが重要です。これにより、再発を未然に防ぎ、長期的なシステムの安定運用を維持できます。システムの安全性と信頼性を確保するためには、焦らず丁寧な対応と、必要に応じた専門家の支援を得ることが最も効果的です。



補足情報


※株式会社情報工学研究所は（以下、当社）は、細心の注意を払って当社ウェブサイトに情報を掲載しておりますが、この情報の正確性および完全性を保証するものではありません。当社は予告なしに、当社ウェブサイトに掲載されている情報を変更することがあります。当社およびその関連会社は、お客さまが当社ウェブサイトに含まれる情報もしくは内容をご利用されたことで直接・間接的に生じた損失に関し一切責任を負うものではありません。



このページと関連する記事：