web-dev-qa-db-ja.com

Sudo chown -R $ USER $ USER / usr / lib /を実行した後、インターネットにアクセスできません

私はPyCharmを更新したかったのですが、Pycharmを実行しているとき、十分な権限がないと言われたため、それは不可能でした。そこで、次のコマンドを実行します。

$ Sudo chown -R $USER$USER /usr/lib/

PyCharmを正常に更新できましたが、今ではインターネット接続が機能していません。実際、 このチュートリアル に従ってリカバリモードにアクセスした後、Sudoを実行できませんでした。

インターネット接続が再び正常に機能する必要があるため、この問題を解決するためのご協力をお願いいたします。

デュアルブートを使用していることに言及する必要があります。

command-linenetworkingpermissionschown
4
lmiguelvargasf

システムディレクトリに対するあらゆる種類のchown操作は、非常に危険なです。

この問題を解決する最も簡単な方法は、オペレーティングシステムを完全に再インストールすることです。

運がよければ（そして少しリスクを冒す人も）、回復モードから次のコマンドを実行するだけで回復できる場合があります。

chown -R root:root /usr/lib

mostファイルは/usr/libのルートによって所有されていますが、isn 'tこれは、適切なユーザーが積極的に所有していない場合に大きな問題を引き起こします。実際、（平均的な）Linuxインストールでは、このディレクトリ内のほとんどのファイルはroot/rootによって所有されているため、再インストールが望ましくない場合は間違いなく一見の価値があります。

それ以外の場合は、各ファイルを調べて、アクセス許可を手動で通常の値（通常はrootが所有することを意味しますが、すべての場合を除く）に手動で再割り当てする必要があります。時々、すべてのパッケージを（apt --reinstall install <packagename>を使用して）再インストールすることもできますが、これは保証されておらず、解決するよりも多くの頭痛の種を引き起こす可能性があります。本当に、各ファイルを調べて、dpkg -Lを実行することになります。

現在のシステムでファイルを保存する場合（OSパスを再インストールする場合）、リカバリモードでフラッシュドライブを使用できます。最後の1秒間にいくつかのファイルをGitにアップロードする必要がある場合は、おそらくライブDVDを使用できます（SSHキーや、破損したインストールから重要なものを引き出します）。

将来、この種の問題が再び発生するのを防ぐために、システムと重要なファイルのバックアップ（動作中-確認してください）があることを確認してください。

また、Sudoがnotのすべてのワンショット修正ソリューションであることに注意することが重要です。許可エラーであり、そのように使用しないでください！許可エラーが発生した場合、おそらくそれを実行する許可を持っていない非常に正当な理由があるので、適切な方法で調査して解決してください。

9
Kaz Wolfe

実際には、再インストールする必要はありません。この状況はかなり回復可能です。システムで同じコマンドを実行し、約10分で修正しました。

リカバリモードで起動するか、LinuxバージョンのライブUSB/DVD（できればUbuntu！）を使用する必要があります。

復旧を希望する場合は、 復旧モードで起動するにはどうすればよいですか を参照してください

Xubuntu 16.04でライブUSBを使用しました。ライブセッションを使用する場合は、起動後にターミナルを開き、lsblkやSudo fdisk -lなどのコマンドを使用してルート（メイン）パーティションを特定します。どのパーティションか（ext4パーティションである可能性が高い）がわかったら、マウントします。ここでは、ルートパーティション/dev/sda1を呼び出しています。これを実際のラベルに置き換える必要があります。

Sudo mount /dev/sda1 /mnt

ls /mntを実行して、適切なパーティションであることを確認してください-usr sys proc dev home rootなど、ファイルシステムツリーの最上部にあると思われるものが表示されます。 OK、所有権を修正しましょう（これらのすべてのコマンドで、:に注意して、正しい場所に配置してください）。

Sudo chown -R root: /mnt/usr/lib

それはほとんどそれを修正します。私のシステムでは、それを壊す前に、その場所のすべての所有権をチェックアウトしました

$ find /usr/lib -not -user root

何も返さない-rootはすべてを所有しているが、

$ find /usr/lib -not -group root -ls

これを明らかにした：

-rwxr-sr-x   1 root     mail          /usr/lib/emacs/24.5/x86_64-linux-gnu/movemail
-rwxr-sr-x   1 root     tty           /usr/lib/mc/cons.saver
-rwsr-xr--   1 root     messagebus    /usr/lib/dbus-1.0/dbus-daemon-launch-helper
-rwxr-sr-x   1 root     utmp          /usr/lib/x86_64-linux-gnu/utempter/utempter

システムは完全に同じではありませんが、それらのファイルがある場合はchown、そうでない場合は同等のものを探す必要があります（たとえば、システムが32ビットの場合、代わりにx86がありますx86_64）。私はこれらを修正しました：

Sudo chown :mail /mnt/usr/lib/emacs/24.5/x86_64-linux-gnu/movemail
Sudo chown :tty /mnt/usr/lib/mc/cons.saver
Sudo chown :messagebus /mnt/usr/lib/dbus-1.0/dbus-daemon-launch-helper
Sudo chown :utmp /mnt/usr/lib/x86_64-linux-gnu/utempter/utempter

（リカバリモードを使用する場合、これらのパスの開始時に/mntは必要ありません）

@ -grawityによる 指摘 として、setuidによってクリアされるdbus-daemon-launch-helperのchownビットも修復する必要があります。

Sudo chmod u+s /mnt/usr/lib/dbus-1.0/dbus-daemon-launch-helper
14
Zanna