ユーザーの所属グループを確認して権限の実態を把握する手順

ユーザーがどのグループに所属しているかは、ファイルアクセス・sudo実行・デバイス操作など、あらゆる権限判断の根拠です。「なぜこのユーザーはこの操作ができないのか」を調べるときの第一歩は、必ずグループ確認から始まります。

所属グループを確認する最短コマンド

まず結論です。id コマンドにユーザー名を渡すだけで、uid・プライマリグループ・補助グループがまとめて確認できます。

id tomohiro

出力例：

uid=1001(tomohiro) gid=1001(tomohiro) groups=1001(tomohiro),4(adm),27(sudo),998(docker)

引数なしで id を実行すると、現在ログインしているユーザー自身の情報を表示します。リモートサーバーで「自分が今どの権限で作業しているか」をすぐに把握したいときにも使えます。

出力フィールドの読み方

出力には3つのフィールドが含まれます。それぞれの意味を押さえておくと、権限トラブルの原因を素早く特定できます。

• uid：ユーザーID。ファイルの所有者判定に使われます。
• gid：プライマリグループID。新規作成ファイルのデフォルトグループはここで決まります。
• groups：プライマリグループを含む全所属グループの一覧。ここに表示されていないグループの権限は持ちません。

上の例では sudo（番号27）と docker（番号998）が含まれているため、このユーザーは管理者コマンドの実行と Docker の操作が可能です。グループ番号はディストリビューションや環境によって変わるため、番号ではなく名前で判断するのが実務では基本です。

なお、グループ情報は /etc/group に記録されており、手動で確認することもできます。ただし LDAP や Active Directory と連携している環境では /etc/group だけに頼ると情報が不完全になるため、後述の getent を使うほうが確実です。

グループ名だけをシンプルに確認したい場合

IDや番号が不要でグループ名だけを見たいときは groups コマンドが便利です。

groups tomohiro

tomohiro : tomohiro adm sudo docker

引数なしで実行すると、自分自身のグループ一覧を表示します。スクリプトで処理しやすい形式が必要な場合は、以下のように加工できます。

# グループ名を1行ずつ出力する
id -Gn tomohiro | tr ' ' '\n'

特定のグループに属しているかどうかをスクリプト内で判定したい場合は、次のように書くと明示的です。

# docker グループに属しているか確認（終了コード 0 なら属している）
id -Gn tomohiro | grep -qw docker && echo "docker グループあり" || echo "docker グループなし"

特定グループのメンバー全員を逆引きする

逆方向の調査、つまり「このグループには誰が属しているか」を知りたい場合は getent group を使います。LDAP 連携環境でも /etc/group に記載のないユーザーを含めて取得できるため、単純に cat /etc/group を見るより確実です。

# sudo グループのメンバーを確認
getent group sudo

# docker グループのメンバーを確認
getent group docker

sudo:x:27:tomohiro,alice
docker:x:998:tomohiro

出力の最後のフィールド（最後の : の後）がメンバー一覧です。ただし、そのグループをプライマリグループとして設定されているユーザーはここに表示されないことがあります。完全な確認が必要な場合は id ユーザー名 も必ず併用してください。

グループ追加後に反映されない場合の対処

ユーザーを新しいグループに追加しても、現在ログイン中のセッションには即座に反映されません。グループ情報はログイン時に読み込まれるため、追加後すぐに id を実行しても新しいグループが表示されないことがあります。

再ログインせずに反映させるには newgrp を使います。

# 新しいグループに切り替えてサブシェルを起動
newgrp docker

# 反映されたか確認
id

ある運用現場では、Docker をインストール後に docker グループへの追加は完了しているのに「Permission denied」が出続けるトラブルが発生しました。原因は再ログインを忘れていただけで、newgrp docker の実行か SSH の再接続で即解決しています。

SSH 接続の場合は切断して再接続するのが確実です。newgrp はサブシェルを起動する仕組みのため、exit で元のシェルに戻るとグループが元に戻ります。永続的に反映したい場合は必ず再ログインしてください。

管理者グループへの追加と確認の流れ

グループ確認の次によく行う作業が「グループへの追加」です。ディストリビューションによって管理者グループ名が異なります。

Ubuntu / Debian 系：

# sudo グループに追加（-aG を必ずセットで使う）
sudo usermod -aG sudo tomohiro

# 反映確認
id tomohiro

AlmaLinux / Rocky Linux / RHEL 系：

sudo usermod -aG wheel tomohiro

id tomohiro

-a（append）を付けずに -G だけ使うと、既存の補助グループがすべて上書きされて削除されます。docker グループや adm グループを含む大事な権限が消えてしまうため、-aG はセットで使うのが鉄則です。

追加後は必ず id tomohiro で意図したグループが含まれているかを確認し、対象ユーザーに再ログインを促してから作業を締めてください。確認を省くと「追加したはずなのに操作できない」という問い合わせが後から来ることになります。

なお、systemd-journald のログを一般ユーザーが閲覧できるようにする systemd-journal グループや、特定デバイスへのアクセスに必要な dialout・plugdev グループなど、現代の Linux 環境ではディストリビューション固有のグループが多数存在します。権限トラブルに遭遇したら ls -l でファイルの所属グループを確認し、id でユーザーのグループと照合する流れを習慣にすると、原因特定のスピードが大きく変わります。