Permission deniedの原因と直し方｜6つの切り分け手順

Permission denied は「そのファイルを触る権限が、いま自分にはない」とOSが返しているエラーです。原因は実行権限（x）の不足だけでなく、親ディレクトリ・所有者・ACL・マウントオプションなど6種類あり、どれかによって直し方がまったく変わります。

検索すると「chmod 777 にすれば直る」という説明が多く出てきますが、これは直らないどころか事態を悪化させるケースがあります。実際、SSHの ~/.ssh を777にすると接続は成功から失敗に変わります（後半で実測します）。

この記事ではUbuntu 24.04の実機とDockerを使い、Permission denied が出る6つの原因を1つずつ再現して、「どこで拒否されたか」を特定する手順にまとめます。まずは、原因が分からないときに最初に打つ3行から。

ls -l 対象ファイル          # 権限・所有者を見る
namei -l 対象ファイルのフルパス   # パスの途中で止まっていないか見る
id                        # 自分が誰で、どのグループに属しているか見る

この3つで、6原因のうち4つはその場で判別できます。以下、順番に見ていきます。

Permission deniedとは｜errno 13（EACCES）をシェルがそのまま表示している

Permission denied は、Linuxカーネルがシステムコールに対して返すエラー番号13番（EACCES）の定型メッセージです。cat や bash といったコマンドは、このエラー番号を受け取って人間向けの文字列に変換しているだけで、メッセージを出しているコマンド自体に問題があるわけではありません。

実際にPythonから /etc/shadow（root専用のパスワードファイル）を開いて、返ってくる番号を確認してみます。

python3 -c "
import errno, os
try:
    open('/etc/shadow')
except OSError as e:
    print('errno', e.errno, errno.errorcode[e.errno], '|', os.strerror(e.errno))
"

errno 13 EACCES | Permission denied

同じ状況を cat で起こすと、次のように表示されます。

$ cat /etc/shadow
cat: /etc/shadow: Permission denied
$ echo $?
1

終了ステータスで「何が拒否されたか」が分かる

実は、直前のコマンドの終了ステータス（echo $?）を見るだけで、原因の当たりがかなり絞れます。同じ「Permission denied」でも数字が違うためです。実機で確認した結果が次の表です。

終了ステータス	意味	実際のメッセージ例
126	ファイルは見つかったが実行できない	bash: ./hello.sh: Permission denied
127	コマンド自体が見つからない（権限とは無関係）	bash: notacommand: command not found
1	コマンドは動いたが対象を読み書きできない	cat: /etc/shadow: Permission denied

126が出たらスクリプトやバイナリの実行権限まわり、1が出たらファイルの読み書き権限まわりと切り分けられます。127は「そもそもパスが違う・インストールされていない」なので、権限を触っても直りません。

権限表記そのものの読み方（rwxr-xr-x と 755 の対応など）に不安があれば、パーミッションとは？Linuxの権限の仕組みとchmodによる変更方法を先に読んでおくと以降が理解しやすくなります。

原因① 実行権限（x）がない｜もっとも多いケース

作ったばかりのシェルスクリプトを実行しようとして怒られる、という定番のパターンです。実際に再現します。

mkdir -p /tmp/pd && cd /tmp/pd
printf '#!/bin/bash\necho "hello from script"\n' > hello.sh
ls -l hello.sh
./hello.sh
echo $?

-rw-rw-r-- 1 mugi mugi 37 Aug  2 08:53 hello.sh
bash: ./hello.sh: Permission denied
126

権限が -rw-rw-r-- でxが1つもありません。ファイルを作った直後の既定値は「読み書きはできるが実行はできない」なので、これは正常な動作です。

bash script.sh なら動く、という重要な手がかり

ここで覚えておくと役に立つのが、同じファイルでも bash hello.sh なら実行権限なしで動くという点です。

$ bash hello.sh
hello from script
$ echo $?
0

この場合に実行されているのは bash であり、hello.sh は単なる「読み込まれるテキスト」だからです。つまり「./x.sh はダメだが bash x.sh は通る」なら、原因はほぼ確実にxビット不足と判定できます。逆に bash x.sh でも Permission denied なら、読み取り権限か親ディレクトリ側の問題です。

直し方

chmod +x hello.sh
./hello.sh
echo $?

hello from script
0

chmod +x は所有者・グループ・その他すべてにxを付けます。自分だけが実行できれば十分な場面では chmod u+x hello.sh のほうが安全です。

原因② 親ディレクトリにxがない｜いちばん見落とされる罠

「ファイル自体は644なのに読めない」という不可解な状況の正体がこれです。Linuxではディレクトリのxビットは「中を通り抜ける権限」を意味し、これが無いとその配下のファイルには権限がどうであれ一切アクセスできません。

mkdir -p vault
echo "secret data" > vault/note.txt
chmod 644 vault/note.txt
chmod 644 vault          # ディレクトリからxを外す
ls -ld vault
ls -l vault/note.txt
cat vault/note.txt

drw-r--r-- 2 mugi mugi 4096 Aug  2 08:54 vault
ls: cannot access 'vault/note.txt': Permission denied
cat: vault/note.txt: Permission denied

注目したいのは、自分が所有者であり、ファイルにも読み取り権限があるのに読めないという点です。ls -l vault/note.txt の段階ですでに拒否されるため、「ファイルの権限を確認しようとしても確認できない」という状態になります。ここで多くの人が混乱します。

namei -l でどの階層で止まったかを一発で見る

こういうときに使うのが namei -l です。フルパスを根元から1階層ずつ辿って、それぞれの権限と所有者を並べてくれます。

namei -l /tmp/pd/vault/note.txt

f: /tmp/pd/vault/note.txt
 drwxr-xr-x root root /
 drwxrwxrwt root root tmp
 drwxrwxr-x mugi mugi pd
 drw-r--r-- mugi mugi vault
                      note.txt - Permission denied

出力の最後で note.txt - Permission denied と止まり、その直前の vault が drw-r--r--（xなし）であることが一目で分かります。Permission denied で原因が分からないときは、対象ファイルではなくパス全体を namei -l に渡すのが最短ルートです。コマンドの詳しい使い方はnamei｜パス名を辿って各要素の種類や権限を表示するにまとめています。

$ chmod 755 vault
$ cat vault/note.txt
secret data

ディレクトリを 755 に戻せば通ります。ディレクトリに 644 を設定してはいけないのはこのためで、ディレクトリは原則 755（または 700）です。

cd できないのも同じ原因

$ ls -ld /srv/locked
drw-r----- 2 root root 4096 Aug  2 08:56 /srv/locked
$ cd /srv/locked
bash: cd: /srv/locked: Permission denied

cd はまさに「ディレクトリを通り抜ける」操作なので、xビットが無ければ入れません。読み取り（r）だけがあると ls で名前は見えるのに中身に触れない、というちぐはぐな挙動になります。

原因③ 所有者・グループが違う｜idと突き合わせる

権限は「所有者・グループ・その他」の3区分で判定され、最初にマッチした区分だけが適用されます。所有者がrootのファイルを一般ユーザーが触ろうとすれば「その他」の権限しか使われません。

$ id
uid=1000(mugi) gid=1000(mugi) groups=1000(mugi),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),101(lxd),988(docker)
$ stat -c '%A %U:%G %n' /etc/shadow
-rw-r----- root:shadow /etc/shadow

/etc/shadow は「所有者rootは読み書き、グループshadowは読み取り、その他は一切不可」です。id の出力に shadow グループが無いので、読めないのが正解の挙動になります。

グループを追加して解決する場合、グループの変更は再ログインするまで反映されません。これが「usermod したのに直らない」の原因です。

sudo usermod -aG グループ名 $USER
# ここで一度ログアウト＆ログインし直す（またはそのシェルだけなら newgrp グループ名）
id   # 反映されたか確認

-a を忘れて usermod -G と書くと既存の所属グループが全部消えます。sudoグループから外れて操作不能になる事故が起きやすいので、必ず -aG をセットで覚えてください。ユーザーとグループの扱いはLinuxでユーザーを作成する方法｜useraddコマンドの使い方を解説でも触れています。

原因④ ACLで個別に拒否されている｜ls -lの「+」が目印

ここからは頻度は下がるものの、知らないと絶対に解けないパターンです。ACL（アクセス制御リスト）を使うと、通常の3区分とは別に「このユーザーだけ拒否」といった設定ができます。

# root側でACLを設定
echo "data" > /tmp/report.txt
chmod 644 /tmp/report.txt
setfacl -m u:bob:--- /tmp/report.txt
ls -l /tmp/report.txt

-rw-r--r--+ 1 root root 5 Aug  2 08:57 /tmp/report.txt

権限は 644 のままで「誰でも読める」ように見えます。ところがbobが読むと拒否されます。

$ cat /tmp/report.txt
cat: /tmp/report.txt: Permission denied

唯一の手がかりは、ls -l の権限表記の末尾に付いた+ の1文字です。これが付いていたらACLが設定されている合図なので、getfacl で中身を確認します。

$ getfacl /tmp/report.txt
# file: tmp/report.txt
# owner: root
# group: root
user::rw-
user:bob:---
group::r--
mask::r--
other::r--

user:bob:--- が犯人です。解除して再確認します。

$ setfacl -x u:bob /tmp/report.txt
$ cat /tmp/report.txt      # bobとして実行
data

ACLは共有サーバーやNAS由来のファイルで使われていることがあります。chmod を何度やっても効かない場合は、まず + の有無を疑ってください。

原因⑤ noexecでマウントされている｜rootでも実行できない

これは「sudo を付けても直らない Permission denied」の代表格です。ファイルシステムが noexec オプション付きでマウントされていると、xビットが立っていてもroot本人でも実行が拒否されます。/tmp や /var をnoexecにしているサーバーはめずらしくありません。

Dockerで noexec の領域を作って再現します。

docker run --rm --privileged ubuntu:24.04 bash -c '
mount -t tmpfs -o noexec tmpfs /mnt
printf "#!/bin/bash\necho ok\n" > /mnt/run.sh
chmod 755 /mnt/run.sh
ls -l /mnt/run.sh; echo "uid=$(id -u)"
/mnt/run.sh; echo "exit=$?"
bash /mnt/run.sh; echo "exit=$?"
findmnt -no TARGET,FSTYPE,OPTIONS /mnt
'

-rwxr-xr-x 1 root root 20 Aug  2 08:54 /mnt/run.sh
uid=0
bash: /mnt/run.sh: Permission denied
exit=126
ok
exit=0
/mnt tmpfs  rw,noexec,relatime,inode64

権限は -rwxr-xr-x、実行しているのは uid=0（root）。それでも直接実行は126で弾かれ、bash /mnt/run.sh 経由なら通っています。「root なのに Permission denied」「chmod 777 にしても直らない」ときは、まず findmnt でマウントオプションを見るのが正解です。

# 対象ファイルが乗っているファイルシステムのオプションを確認
findmnt -no TARGET,FSTYPE,OPTIONS -T /path/to/script.sh

対処は、noexecでない場所（多くは /usr/local/bin やホームディレクトリ）にスクリプトを置き直すことです。運用ポリシーとしてnoexecが指定されている領域を勝手に解除するのは避けてください。

原因⑥ SELinux／AppArmorに止められている

RHEL・Rocky Linux・AlmaLinux系ではSELinux、Ubuntu系ではAppArmorという追加の強制アクセス制御が動いています。通常の権限がすべて正しくてもこちらで拒否されるため、ls -l をいくら見ても原因が見つかりません。Webサーバーが特定のディレクトリだけ読めない、といった症状で疑います。

# SELinux（RHEL系）— 有効かどうかとファイルのラベルを確認
getenforce
ls -lZ /var/www/html

# 直近の拒否ログを見る
sudo ausearch -m avc -ts recent

# AppArmor（Ubuntu系）— 有効なプロファイルと拒否ログ
sudo aa-status
sudo journalctl -k | grep -i apparmor

getenforce が Enforcing を返し、ausearch に該当の avc: denied が出ていればSELinux由来です。この場合の対処は setenforce 0 で無効化することではなく、restorecon -Rv /var/www/html でラベルを正しく貼り直すことです。無効化は原因の切り分けには使えますが、そのまま運用してはいけません。

なお、この記事の検証環境はUbuntu 24.04（AppArmor）のため、SELinuxの出力例は実測していません。上記コマンドは確認手順として参照してください。

sudoで直るケース・直らないケース

ここまでを踏まえると、sudo が効く場面と効かない場面をきれいに整理できます。

原因	sudoで直るか	正しい対処
① 実行権限（x）がない	△ 一時的には動く	chmod +x
② 親ディレクトリにxがない	○	ディレクトリを 755 に
③ 所有者・グループが違う	○	chown か usermod -aG
④ ACLで拒否	○	setfacl -x
⑤ noexecマウント	×	別の場所へ移動
⑥ SELinux／AppArmor	×	restorecon でラベル修正

sudo を付けたのに Permission denied になる最頻パターン

⑤⑥以外にもう1つ、非常によく踏むのがリダイレクトの罠です。

$ sudo echo test > /root/out.txt
bash: /root/out.txt: Permission denied
$ echo $?
1

root権限で実行されているのは echo だけで、> によるファイル作成は sudo を打った本人のシェルが行っているためです。sudoは > より後ろには効きません。正しくは tee を挟みます。

$ echo test | sudo tee /root/out.txt > /dev/null
$ sudo ls -l /root/out.txt
-rw-r--r-- 1 root root 5 Aug  2 08:56 /root/out.txt

追記したい場合は sudo tee -a を使います。sudo 自体の仕組みや sudoers の設定はsudoコマンドの使い方｜root権限の取得とsudoersの設定で詳しく扱っています。

「Operation not permitted」との違い

似たエラーに Operation not permitted があります。こちらはerrno 1（EPERM）で、Permission denied（errno 13）とは別物です。ざっくり言えば次の違いになります。

メッセージ	errno	意味
Permission denied	13（EACCES）	権限が足りない。適切なユーザーになれば通る
Operation not permitted	1（EPERM）	操作そのものが許されていない。rootでも通らないことがある

典型例が、chattr +i で設定する「変更不可（immutable）」属性です。rootでも削除できません。

$ lsattr f.txt
----i---------e------- f.txt
$ rm -f f.txt          # rootで実行
rm: cannot remove 'f.txt': Operation not permitted
$ echo more >> f.txt
bash: f.txt: Operation not permitted

rootなのに Operation not permitted が出たら lsattr を確認してください。i が立っていれば chattr -i ファイル名 で解除できます。設定ファイルの誤更新防止のために意図的にかけられていることもあるので、外す前に理由を確認しましょう。

場面別｜よくあるPermission deniedと直し方

ssh: Permission denied (publickey)

SSHの Permission denied は、末尾の括弧が「どの認証方式で断られたか」を示しています。(publickey) なら公開鍵認証で拒否されたという意味です。

ここで強調したいのが、chmod 777 はSSHでは逆効果という点です。sshdは StrictModes により、~/.ssh や authorized_keys が他人から書き込める状態だと鍵を読み込みません。Dockerでsshdを立てて実測しました。

=== 1) 正しいパーミッション (700/600) ===
drwx------ 2 alice alice 4096 Aug  2 08:56 /home/alice/.ssh
-rw------- 1 alice alice 100 Aug  2 08:56 /home/alice/.ssh/authorized_keys
LOGIN_OK

=== 2) ~/.ssh を 777 に変更 ===
drwxrwxrwx 2 alice alice 4096 Aug  2 08:56 /home/alice/.ssh
alice@localhost: Permission denied (publickey,password).

--- サーバー側ログ ---
Authentication refused: bad ownership or modes for directory /home/alice/.ssh

権限を緩めた結果、成功していたログインが失敗に変わりました。サーバー側のログには bad ownership or modes と明記されています。接続元ではなく接続先サーバーで次の権限を確認してください。

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chmod 600 ~/.ssh/id_ed25519      # 接続元の秘密鍵
chown -R $USER:$USER ~/.ssh

ホームディレクトリ自体が 777 になっていても同じ理由で拒否されます。原因が分からないときは、接続先で sudo journalctl -u ssh -n 30 を見るのが最短です。切り分けの全体像はSSH接続できないときのチェックリスト｜bashで原因を切り分ける手順、鍵の作成手順はパスワードなしでSSHログイン｜公開鍵認証の設定と運用の基本にまとめています。

docker: permission denied while trying to connect to the Docker daemon socket

Dockerをインストールした直後に必ず出るエラーです。実際に非rootユーザーで叩くと次のようになります。

permission denied while trying to connect to the docker API at unix:///var/run/docker.sock

原因はソケットファイルの権限で、これは原因③（グループ不一致）の一種です。

$ ls -l /var/run/docker.sock
srw-rw---- 1 root docker 0 Aug  1 09:15 /var/run/docker.sock

所有グループが docker、その他には権限なし。つまりdockerグループに入っていないユーザーは弾かれるのが正しい設計です。

sudo usermod -aG docker $USER
# ログアウト＆ログインし直す
id | tr ',' '\n' | grep docker

988(docker) のように表示されれば反映済みです。sudo chmod 666 /var/run/docker.sock は絶対に避けてください。Dockerソケットへの書き込み権限は事実上のroot権限に等しく、全ユーザーに開放することになります。docker コマンド自体の使い方はdocker｜コンテナ/イメージを操作するDocker CLIの基底コマンドを参照してください。

find で Permission denied が大量に流れる

find の場合、Permission denied は「探索できなかったディレクトリの報告」であって失敗ではありません。検索結果自体は正常に出ています。

$ find /etc -name "*.key"
find: '/etc/polkit-1/rules.d': Permission denied
find: '/etc/ssl/private': Permission denied
find: '/etc/lvm/backup': Permission denied
find: '/etc/lvm/archive': Permission denied

これらのメッセージは標準エラー出力（stderr）に出ているので、2>/dev/null で捨てれば結果だけが残ります。

# エラーだけ捨てる（結果は残る）
find /etc -name "*.key" 2>/dev/null

# 読めるものだけを対象にする（より明示的）
find /etc -readable -name "*.key"

全部を確実に探したいなら sudo find ... を使います。find の条件指定はfind｜ファイルやディレクトリを検索するコマンドにまとめています。

scp・rsync の Permission denied

転送系は「接続で断られた」のか「書き込みで断られた」のかを見分けます。

$ scp f.txt user@host:/etc/
user@host: Permission denied (publickey,password).
scp: Connection closed

これはログインの段階で断られており、ファイル権限とは無関係です。前述のSSHの項を参照してください。一方、次はログインに成功したうえで書き込みに失敗した例です。

$ rsync -a f.txt /etc/
rsync: [receiver] mkstemp "/etc/.f.txt.62e9WX" failed: Permission denied (13)
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1356) [sender=3.2.7]

末尾に (13) とerrnoが出ているのが分かりやすい点です。転送先ディレクトリの書き込み権限を確認します。なお rsync は一時ファイル（.f.txt.XXXXXX）を作ってから置き換えるため、転送先ディレクトリ自体にwが必要です。

Permission denied ではないのに紛らわしいエラー

スクリプトが動かないとき、次のメッセージは権限とは無関係です。実機での出力を並べます。

メッセージ	終了ステータス	原因
cannot execute: required file not found	127	シバン（1行目）の指定先が存在しない。改行コードがCRLFの場合も含む
Is a directory	126	ファイルではなくディレクトリを実行しようとした
command not found	127	PATHが通っていない、未インストール

特に注意したいのが、WindowsからアップロードしたスクリプトのCRLF改行です。1行目が #!/bin/bash\r と解釈されるため「そんなインタプリタは無い」と怒られます。file script.sh で with CRLF line terminators と出たら、sed -i 's/\r$//' script.sh か dos2unix script.sh で変換してください。

やってはいけない対処

最後に、検索でよく出てくるものの実務では避けるべき対処を挙げます。

• chmod -R 777｜誰でも書き換え・実行できる状態になります。Webサーバー配下で行うと、アップロードされたファイルがそのまま実行される踏み台になり得ます。SSH関連では前述のとおり逆に接続できなくなります。
• sudo chmod 666 /var/run/docker.sock｜実質的に全ユーザーへroot権限を配ることになります。usermod -aG docker を使ってください。
• setenforce 0 のまま運用｜SELinuxを切れば動きますが、防御機構を丸ごと止めています。切り分けに使うのは可、恒久対処にするのは不可です。
• chown -R root:root で「揃える」｜Webサーバーが書き込めなくなり、別のPermission deniedを生みます。所有者はそのプロセスを動かしているユーザーに合わせます。
• すべてを sudo で実行する｜生成されたファイルの所有者がrootになり、後から一般ユーザーで触れなくなって同じエラーが再発します。

基本方針は「ファイルは644、ディレクトリは755、必要な相手だけをグループで追加する」です。具体的な修正手順は権限エラーが出たらこれ！chown・chmodの基本と安全な直し方で、新規作成時の既定権限を決める仕組みはumask｜新規ファイルやディレクトリ作成時のデフォルト権限を制御するコマンドで扱っています。

切り分けフローまとめ

ここまでの内容を、上から順に試すだけで原因にたどり着ける形に並べ直します。

1. echo $? で終了ステータスを見る。126なら実行系、1なら読み書き系、127は権限と無関係。
2. namei -l フルパス でどの階層で止まったかを見る。パスの途中で止まっていれば原因②。
3. ls -l と id を突き合わせる。所有者・グループが噛み合っていなければ原因③。
4. ls -l の末尾に + があれば getfacl を見る。原因④。
5. bash script.sh なら動くか試す。動けば原因①（xビット不足）。
6. rootでも駄目なら findmnt -T パス でnoexecを確認。原因⑤。
7. それでも駄目なら getenforce / aa-status と拒否ログを見る。原因⑥。

よくある質問

chmod 777 にすれば必ず直りますか？

直りません。noexecマウントとSELinux／AppArmorによる拒否は権限とは別の層なので、777にしても弾かれます。またSSHでは ~/.ssh を777にすると StrictModes により逆に接続できなくなります。原因を特定してから最小限だけ変更してください。

ファイルは644なのに読めません。なぜですか？

親ディレクトリのxビット（通り抜け権限）が無い可能性が高いです。namei -l にフルパスを渡すと、どの階層で止まっているかが分かります。ディレクトリは 644 ではなく 755 が正解です。

sudo を付けても Permission denied になります

3つを疑ってください。（1）sudo cmd > file のようにリダイレクトを使っている（> はsudoの外側なので sudo tee に置き換える）、（2）noexecでマウントされている、（3）SELinuxが拒否している。いずれもrootでは解決しません。

Permission denied と Operation not permitted の違いは？

前者はerrno 13（EACCES）で「権限が足りない」、後者はerrno 1（EPERM）で「その操作自体が許されていない」です。rootで Operation not permitted が出たら lsattr でimmutable属性（i）を確認し、chattr -i で解除します。

usermod でグループを追加したのに直りません

グループの変更はログインし直すまで反映されません。id を実行して新しいグループが表示されるか確認してください。そのシェルだけで反映したい場合は newgrp グループ名 が使えます。また -a を付けずに usermod -G と実行すると既存の所属グループが消えるため、必ず -aG を使ってください。

スクリプトの1行目は正しいのに実行できません

改行コードがCRLFになっていないか file script.sh で確認してください。with CRLF line terminators と表示されたら sed -i 's/\r$//' script.sh で修正します。この場合のメッセージは Permission denied ではなく cannot execute: required file not found（終了ステータス127）になります。

関連記事

• パーミッションとは？Linuxの権限の仕組みとchmodによる変更方法｜755 と rwxr-xr-x の対応を基礎から
• 権限エラーが出たらこれ！chown・chmodの基本と安全な直し方｜WordPress運用での修正手順
• namei｜パス名を辿って各要素の種類や権限を表示する｜原因②の特定に必須
• sudoコマンドの使い方｜root権限の取得とsudoersの設定｜sudoの効く範囲を正しく理解する
• umask｜新規ファイルやディレクトリ作成時のデフォルト権限を制御するコマンド｜そもそもなぜ644で作られるのか
• SSH接続できないときのチェックリスト｜bashで原因を切り分ける手順｜publickey拒否の全体像
• find｜ファイルやディレクトリを検索するコマンド｜大量のPermission deniedを抑制する

参照リンク

• errno(3) — Linux manual page（EACCESとEPERMの定義）
• execve(2) — Linux manual page（noexecやxビットによるEACCESの条件）
• sshd_config — StrictModes（SSHがパーミッションを検査する仕様）
• Docker Docs — Linux post-installation steps（dockerグループの追加手順）

検証環境：Ubuntu 24.04.4 LTS（カーネル6.8.0）、bash 5.2、OpenSSH 9.6p1、GNU findutils 4.9.0、rsync 3.2.7。noexec・ACL・sudo・sshdの各検証はDocker（ubuntu:24.04）上で実施しています。