Debianサーバーでドライブ内のファイルが書き込めなくなった事象発生

自宅で8TBのHDDをマウントして便利なマイストレージサーバーを構築している環境でトラブル発生です。 ある日を境に急に/etcの設定ファイルや/var/logなどのログファイルの書き込みができなくなってしまいました。 確かにこうなった原因は分かるんですが、問題発生の原因や、事象解決までの道のりを備忘録として残しておきます。

気がついたのは、設定変更しようとした時

nginxを設置して、PHPで便利ツールを沢山作りこんでいるサーバーなのですが、サブドメインなどの追加により、/etc/nginx/site_enabled/***.confファイルを変更しようとした時に、root権限でviでファイル編集すると、何故か「error readonly file」というメッセージが出てきて、ファイルが上書きできません・・・ 最初は何が起こっているのか分からず、rootで書き込めないファイルがあるという事実だけがわかりました。 そして色々調査してみると、/ver/log内にあるシスログデータが全てある日を境に書き込みが止まっており、まるでシステムの書き込み機能が全て遮断しているようにも見えます。 案の定、home領域のファイルも含めて、起動ドライブ内の全てのファイルがreadonly権限であるというメッセージが表示されていました。 この時のファイル詳細を見ると以下の様になっていました。 -rw-r--r-- 1 root root 759 1月 2 12:59 /etc/hoge.conf 644の権限なので、ちゃんと書き込みできるはずだし、root権限であれば操作が出来るはずなのに・・・ ・・・ん？・・・ドライブ？？？？？・・・ なんとなくピンときました。

思い起こせば外部USB設定を変更したタイミング

数日前に、外部USBドライブの設定を見直す処理をした時のことです。 元々、外部ストレージを後付けで行った関係もあり、サーバーを起動してから外部USBストレージをmountするという手順で運用していたのですが、 停電や、何かの節にコンセントが抜けてしまった場合、OS起動と同時にUSBストレージも一緒にマウントしてもらわないと、なんとも面倒くさいので、 /etc/fstabファイルを編集して起動時に自動マウントする処理を書き込んだ時に、事前に書き込まれていた設定を一つコメントアウトしたのを思い出しました。 # /etc/fstab: static file system information. # # Use 'blkid' to print the universally unique identifier for a # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # # <file system> <mount point> <type> <options> <dump> <pass> # / was on /dev/sda1 during installation UUID=8d696f8b-590c-4302-8bb1-4d807f2d39c2 / ext4 errors=remount-ro 0 1 # swap was on /dev/sda5 during installation UUID=f8e1fec6-5cdf-41cf-b761-d2f44bea8fdd none swap sw 0 0 #/dev/sdb1 /data ext4 defaults 0 0 # /etc/fstab: static file system information. # # Use 'blkid' to print the universally unique identifier for a # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # # <file system> <mount point> <type> <options> <dump> <pass> # / was on /dev/sda1 during installation # UUID=8d696f8b-590c-4302-8bb1-4d807f2d39c2 / ext4 errors=remount-ro 0 1 # sdb ($ mount /dev/sdb /mnt/usb) UUID=194c208e-4ad4-4c0c-a21c-db3bafb20dcb /mnt/usb ext4 defaults 0 0 # swap was on /dev/sda5 during installation UUID=f8e1fec6-5cdf-41cf-b761-d2f44bea8fdd none swap sw 0 0 #/dev/sdb1 /data ext4 defaults 0 0 UUID=194c208e-4ad4-4c0c-a21c-db3bafb20dcb /mnt/usb ext4 defaults 0 0 この行で、外部ストレージをマウントできたんですが、 UUID=8d696f8b-590c-4302-8bb1-4d807f2d39c2 / ext4 errors=remount-ro 0 1 どうやらこの行をコメントアウトしたことにより、システムドライブが書き込み禁止状態になってしまったようです。 基本設定なのに、自分で書き込んだモノとして勘違いしていたようです。アフォですね。 ちゃんとマウント先が/(root)指定されているのに、これ消しちゃまずいでしょ。 そして地獄はここからでした・・・

起動ドライブが書き込みできなくなるとどうなるの？

起動ドライブはシスログを書き溜める役割もあるし、各種OSを動かす全ての設定ファイルが用意されています。 この設定ファイルを書き換えれば、OSの挙動も変わるのですが、書き込み禁止なので、設定ファイルも書き込みできなくなってしまいます。 もちろん、su権限で行ったり、sudoコマンドを使ってもどうやっても、readonlyを回避することはできず、ファイルの書き換えが出来ない状態になってしまいました。 最初に試したのはサーバー起動時にセーフモードで起動しても、書き込み禁止状態は回避できませんでした。 内蔵のHDD(SSD)を取り外して別のパソコンでマウントしてからファイルを直接書き換えるという手もありましたが、わざわざサーバー筐体を解体するのも非常に骨が折れるのでこれは最終手段にしておきましょう。

解決への道

この手の障害は経験したことのある人でないとなかなかセオリーも無いためどのようにググれば良いかもわからない状態ですが、 一度マウントしたドライブを再マウントすることができれば、書き込み権限が復活するかも・・・ という考えが浮かびました。 調べてみると、マウントコマンドの「-o」オプションに「remount」という指定が出来ることが分かり、実行してみた所、どうやら正解でうまくいきました。 以下はroot権限で実行しています。 $ mount -o remount,rw /dev/sda1 その後に対象ファイルをviで修正して、一度確認の為、サーバーを再起動して、書き込みが出来ることを確認できれば、完了です。 fstabファイルの認識の甘さが今回の失敗を招いたのですが、mountコマンドの-oオプションを若干習得できたので、結果オーライという事にしておきます。 バンザイ失敗！！