更新1:
chown -R gdm:gdm /var/lib/gdm
を適用し、正常にログインできるようになりました。ただし、これが問題を引き起こす程度はわかりません。
-
最近postgresqlインストールをアップグレードし、コマンドを実行するつもりでした。
Sudo chown -R postgres:postgres /var/lib/postgres
残念ながら、タブ補完の計算が間違っていたため、最後に誤って「postgres」の部分を忘れてしまいました...
Sudo chown -R postgres:postgres /var/lib
言うまでもなく、これにより多くの問題が発生しました。たとえば、オペレーティングシステムを起動できません(Update 1を参照)。
ウィンドウマネージャーとしてi3、ディスプレイマネージャーとしてGDMを使用してArch Linuxを実行しています。/var/libの必要なディレクトリに元の所有権を取得するのに役立つ情報をいただければ幸いです。現在のところ、プロセスのこの部分で永続的にハングしています。 luksを使用していますが、ファイルシステムは暗号化されています。
ただし、カーネル行に「init =/bin/bash」を追加することで、grubを介してシェルを生成できます。そのため、適切な所有権の要件を知っていれば、これは簡単に修正できます。/var/libの現在のディレクトリは次のとおりです。
1つの問題は、gdmが所有するgdmフォルダーに、postgresが所有するいくつかのサブディレクトリが含まれていることです。
どんな援助でも大歓迎です。
/var/lib
のファイルの所有権を、chown -R gdm:gdm /var/lib/gdm
を実行する前の状態に戻すにはどうすればよいですか?
/ etc/passwordsのユーザー名と/ etc/groupsのグループから知っている情報を含むディレクトリでchownコマンドを使用して戻ることができ、残りはroot:rootに属します
しかし、バグを許すまでは少し注意が必要です...忘れられた変更のために、それは何日にもわたって現れます...
Postgres gdmは大丈夫だと思います。残りはroot redisからredisに属している可能性があります...専用ユーザーもいると思います。
簡単な方法:すべてを再インストールします(データベースのバックアップ後、もちろん/ homeをフォーマットせずに)...
/ varファイルシステム階層は、アプリケーションによって作成されたデータ用であり、そのため、パッケージマネージャーは/ varでほとんど管理しません。ほとんどの場合、pacman -Qoは/ var/libの最上位ディレクトリの所有権のみを返します。その構造は、各アプリケーションに1つのディレクトリを持たせることです。
最初に、すべてをroot所有者に設定して、postgresよりもより健全なデフォルトを設定します。
chown -R root:root /var/lib/
/var/lib
にファイルを所有しているパッケージを再インストールします
pacman -Qo $(find /var/lib) 2>/dev/null
次に、各ディレクトリの所有者を確認します。
ls -la /var/lib
ルートが所有するディレクトリ内のすべては、ルートが所有します。一方、rootが所有していないディレクトリは、実際にはアプリケーションユーザーのホームディレクトリです。ほとんど例外なく、これらのディレクトリに含まれるすべてのファイルはアプリケーションユーザーが所有します。したがって、chown -R gdm:gdm /var/lib/gdm
を実行すると機能します。ただし、例外があります。たとえば、私のシステムでは、/var/lib/sddm/state.conf
はrootが所有しています。
これを手動で修正するのは簡単なことではありません。/var/lib
のエントリに基づいて、/etc/passwd
の下のディレクトリの所有権の可能性を推測できますが、ヒットとミスが発生します。アプリケーションディレクトリの下の一部のファイルがアプリケーションによって所有され、他のファイルがルートによって所有されている場合(またはその逆)はどうなりますか?あなたはこれを長い間トラブルシューティングするつもりです...
システムにすべてのパッケージを再インストールすることをお勧めします。これを行うにはさまざまな方法があります。たとえば、次のとおりです。
# pacman -S $(pacman -Qeq) --noconfirm
これを行う前に、システムのバックアップを取ることをお勧めします。