エラーの説明
ファイルを書き込んだりディレクトリを作成しようとすると、次のエラーが表示されます：
touch: cannot touch '/var/log/app.log': Read-only file system
あるいは次のようなバリエーションも：
mkdir: cannot create directory '/etc/myapp': Read-only file system
bash: /tmp/script.sh: Read-only file system
cp: cannot create regular file '/usr/local/bin/mytool': Read-only file system
そのパスにマウントされているファイルシステムが読み取り専用モードに切り替わっています — 意図的に、またはカーネルがエラーを検出して強制的に切り替えた場合があります。
根本原因
Linuxがファイルシステムを読み取り専用として再マウントする主なシナリオは次のとおりです：
- ディスクまたはファイルシステムのエラー — カーネルがI/Oエラーやジャーナルの不整合を検出すると、データ破損を防ぐためにファイルシステムを自動的に読み取り専用に切り替えます。
- 明示的な読み取り専用マウント — ファイルシステムが
roオプションでマウントされています。/etc/fstabか手動のmountコマンドによって設定されています。 - ハードウェア障害 — 劣化したディスク、不良のSATA/SASケーブル、またはデグレードしたRAIDアレイがこれを引き起こす可能性があります。
- コンテナまたはVMの制限 — DockerやKubernetesの設定によっては、ホストファイルシステムを意図的に読み取り専用でマウントする場合があります。
最初のシナリオに特に注意してください。カーネルによる強制再マウントは単なる不便ではなく、ディスクが深刻な問題を抱えている可能性のある警告です。原因を確認せずに読み書き可能に再マウントすると、データ破損がさらに悪化する可能性があります。
手順1：影響を受けているファイルシステムを特定する
エラーが発生しているパスを担当するデバイスを確認します：
df -h /var/log/app.log
出力例：
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 50G 12G 36G 25% /
そのデバイスが読み取り専用でマウントされているか確認します：
mount | grep /dev/sda1
(ro,フラグが読み取り専用の証拠です：
/dev/sda1 on / type ext4 (ro,relatime,errors=remount-ro)
または：
cat /proc/mounts | grep ' / '
手順2：カーネルログで原因を確認する
すぐに修正に飛びつかないでください。まず、なぜ読み取り専用になったか確認します：
dmesg | grep -i 'error\|read-only\|remount\|EXT4\|XFS' | tail -30
またはシステムジャーナルを確認します：
journalctl -k --no-pager | grep -i 'remount\|error\|I/O error' | tail -20
EXT4-fs error、I/O error、またはremounting filesystem read-onlyなどのメッセージが表示されていますか？それはディスクエラーがこれを引き起こしたことを意味します。他に何かする前にファイルシステムチェックを実行してください。
エラーメッセージなしでログがきれいな場合？ファイルシステムは意図的に読み取り専用でマウントされた可能性があります。再マウントの手順に進んでください。
手順3：ディスクの健全性を確認する
dmesgがI/Oエラーを示している場合、ディスクのSMARTデータを取得します：
sudo apt install smartmontools # Ubuntu/Debian
sudo yum install smartmontools # CentOS/RHEL
sudo smartctl -a /dev/sda
SMART overall-health self-assessment test result: FAILEDは即座の警告サインです。しかし、合格した結果でも問題が隠れている可能性があります — Reallocated_Sector_Ct、Current_Pending_Sector、またはOffline_Uncorrectableにゼロ以外の値がないか属性テーブルを確認してください。再割り当てセクターが5つでも真剣に受け止める価値があります。
障害のあるディスクは交換する必要があります。劣化したハードウェアで読み書き可能に再マウントすることは、データ損失のリスクを冒すことになります。
修正A：ファイルシステムを読み書き可能に再マウントする（クイックフィックス）
ディスクの健全性に問題がない場合、または一時的な書き込みアクセスが必要な場合は再マウントします：
sudo mount -o remount,rw /
/を実際のマウントポイントに置き換えます — /var、/homeなど適切なものに：
sudo mount -o remount,rw /var
正常に動作したか確認します：
mount | grep '/var'
# (ro, の代わりに (rw, が表示されるはずです
元のコマンドをテストします：
touch /var/log/app.log
echo $? # 0は成功を意味します
修正B：ファイルシステムチェックを実行する（ディスクエラーがある場合）
カーネルによる強制再マウントは、アンマウントされたファイルシステムに対して適切なfsckが必要です。ルート以外のパーティションの場合は簡単です：
sudo umount /dev/sdb1
sudo fsck -f /dev/sdb1
ルートファイルシステム（/）はより複雑です — システムが実行中はアンマウントできません。最もクリーンなアプローチは、ライブUSBまたはレスキューモードから起動してfsckを実行することです：
fsck -y /dev/sda1
-yフラグはすべての修正を自動的に承認します。fsckが正常に終了したら、再起動するとファイルシステムは読み書き可能になるはずです。
ライブメディアのない古いシステムでは、次回の起動時にチェックをスケジュールできます：
sudo touch /forcefsck
修正C：ファイルシステムが意図的に読み取り専用でマウントされている場合はfstabを修正する
/etc/fstabを開いてroオプションを探します：
cat /etc/fstab
このようなエントリが原因です：
/dev/sda1 / ext4 ro,errors=remount-ro 0 1
ファイルを編集してroをrwに変更します：
sudo nano /etc/fstab
# 変更前: ro,errors=remount-ro
# 変更後: rw,errors=remount-ro
再起動せずに変更を適用します：
sudo mount -o remount,rw /
再起動前に必ずfstabを検証してください — ここに構文エラーがあるとシステムが起動不能になる可能性があります：
sudo findmnt --verify
修正D：ハードウェアの問題を確認する
再マウント後もファイルシステムが読み取り専用になり続ける場合？ディスク自体が本当の原因である可能性があります：
# 不良ブロックをスキャン（遅いが徹底的）
sudo badblocks -v /dev/sda
# SMARTエラー数を直接確認
sudo smartctl -A /dev/sda | grep -E 'Reallocated|Pending|Uncorrectable'
これらの3つの列にゼロ以外の値があれば警告サインです。Reallocated_Sector_Ctが10を超えると、通常はドライブが寿命を迎えつつあることを意味します。今すぐデータをバックアップして交換の計画を立ててください。
確認
修正後、ファイルシステムが実際に書き込み可能であることを確認します：
# マウントフラグを確認
mount | grep rw
# 書き込みテスト
touch /var/log/app.log && echo '書き込みOK' || echo 'まだ読み取り専用'
# 新しいカーネルエラーを確認
dmesg | tail -10
fstabを変更した場合、再起動してマウントが正常に維持されるか確認します：
sudo reboot
# 再起動後:
mount | grep '/dev/sda1'
予防策
- SMARTモニタリングを有効にします：
sudo systemctl enable smartd。バックグラウンドでディスクの健全性を監視し、ドライブが完全に障害を起こす前にメールで通知できます。 dmesgのI/Oエラーに対してアラートを設定します — 出力をログアグリゲーターにパイプするか、I/O errorをgrepして通知を送るcronジョブを設定します。errors=remount-roをext4のfstabエントリに維持してください。これは適切なデフォルトです — 問題が発生したときにデータを保護します。ただし、実際にトリガーされたときに気づくようにモニタリングと組み合わせてください。/var/logを独立したパーティションに配置してください。そうすることで、ルートファイルシステムのエラーが最悪のタイミングでロギングを停止させることを防げます。