2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

研究室の計算機をsudo chown hoge:hoge -R /* で破壊したときの直し方

Last updated at Posted at 2022-12-01

タイトルにあるように

sudo chown hoge:hoge -R /* 

でうっかり計算機を論理的に破壊してしまったときの振り返り記事です。
なんとなく直す方法だけ知りたい方、研究室の高級計算機をバックアップもしてないのに破壊してしまい早急にどうにかしたい方は直し方まで飛んでください。

読み物として読んでいただける方はいきさつからどうぞ。
また、思い出しながら書いているため、実際の挙動と一部異なるかもしれません。

いきさつ

時は今年の四月ごろ、修士の先輩が卒業したため研究室の最強計算機に空きがありました。つよつよGPU4枚刺しの最強計算機、それまで使用していたものからどのくらいプログラムが早く動くのか試してみようとなるのは自然なことです。(4枚刺し、私の好きな言葉です。)

該当の計算機にsshでログイン後、いつものように先輩のGitHubのページからDockerfile等が含まれた作業用環境のリポジトリをクローンしました。そして、dockerコンテナを立てる前に、自身の研究内容に最適化するためVSCodeからDockerfileを書き換え保存しようとするも保存できません。

EACCES: permission denied,~

はいはい、権限ね了解とすでに何度も行っている作業なのですぐに対処法がわかります。GitHubからクローンをすると所有者がrootになるため、所有者をログインしているユーザーに変更するか、所有者以外の権限を書き換える必要がありますがすでに織り込み済みです。

ただ、その作業環境は階層構造になっていたため、再帰的に書き換えるために

sudo chown hoge:hoge -R *

上記のコマンドを打とうとしました。

カタカタカタ

hoge@hoge:~$ sudo chown hoge:hoge -R /*

Enter👆

...........?

hoge@hoge:~$ sudo chown hoge:hoge -R /*
▯

........なぜか帰ってこない。
高々10ファイルもないのに...

あれ...

あっ...

と気づいた瞬間止めたけど手遅れでした。
みごとに所有者がhoge:hogeに書き換えられたファイルの数々。ルートディレクトリから見えるすべてのファイルが所有者hoge:hogeでちょっと笑えました。

まずったかもと思いつつ

hoge@hoge:~$ sudo chown root:root -R /*

でとりあえずどうにかしようとするもエラーが出る。
調べるとどうやらsudoの所有者はrootじゃないと実行できないらしい。
でもsudoの所有者を書き換えるのにsudoが必要で...

とにっちもさっちもいかなくなり、じわじわとやらかしたことのやばさを実感していきました。

そもそもsudo使えなかったら結構なコマンドが使用できない時じゃん...7月の学会に出した先輩のデータがストレージにあるのに...
とここらへんで焦りが最高潮に。

振り返れば人生で一番焦った出来事であり、おそらく走馬灯に出ると思います。

でも、結果的には先輩のデータもサルベージでき、計算機も復旧までこぎつけられました。(研究室の先生も巻き込んで一か月ほどとかしましたが...)以下ではざっくりとした直し方を紹介します。

直し方

ちなみにOSはUbuntu16.04TLSでした。(たしか)
まず、リカバリーモードで入り、rootを選択しましょう。このモードで入ることでsudoなしでコマンドが打てるようになります。参考
このモードのままストレージをマウントしてバックアップを取ることも可能だと思われますが、ここを参考にsudo周りのファイルだけ所有者をrootに戻してバックアップがとれるように復旧しました。
あとはストレージを適当にマウントしてバックアップ後、OSを入れ直しました。
(リカバリーモードから直でマウントしてバックアップを取ったのか、通常起動でターミナルからコマンドを打ってバックアップを取ったのかは忘れました。)

ちなみに、メインのストレージが謎のU.2規格だったり、サーバーに近い計算機なのでIPMI上にOSが載っていたりしましたが、まあどうにかなりました。(前者は秋葉で売っていました。後者は配慮しなくても一般的な手順でOSを入れ直せました。)

終わりに

何かの参考に、またはやらかしのベースラインとして役に立てれば救われる思いです。
また、再帰的に変更するコマンドを打つ場合は細心の注意を払いましょう。この記事のように、失敗すると甚大なダメージを与える可能性があるので、よっぽど階層数/ファイル数が多くない限りはディレクトリ単位で変更を加えていき、再帰オプションは使用しないのが賢いかもしれません。(破壊的なコマンドはrmを実行する時みたいに本当に実行するか聞いてほしい...)

本記事は振り返りで書いたチラ裏のようなものです。参考にして生じた損害の責任は負いかねます。

2
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?