前回の投稿とも関連しているのですが、
https://qiita.com/misoneko315/items/6fca164fa9628f420bb9
LaravelをDocker環境で開発していると、たまに遭遇する Permission denied。
私もこれまで何度も遭遇してきました。
そのたびに、
chown -R www-data:www-data storage
chmod -R 775 storage
のようなコマンドを実行して解決していました。
でも、課題のプロジェクトを完成させることに必死で、詳細な原因調査には至っていませんでした。
chown と chmod の意味は知っていた
-
chown→ 所有者を変更する -
chmod→ 権限を変更する
ここまでは知っています。
でも、「何と何の権限がズレているのか？」は理解できていませんでした。
そのため、
Permission denied
↓
権限エラーっぽい
↓
とりあえず chown
↓
直った
という状態になっていました。
Laravelは誰として動いているのか？
今回、改めて調べるために次のコマンドを実行しました。
docker compose exec php whoami
結果は、
www-data
でした。
つまり、私のDocker環境ではLaravel（正確にはPHPプロセス）は www-data ユーザーとして動いていることになります。
storageの所有者を確認してみる
次に、Laravelが書き込みを行う storage ディレクトリを確認しました。
docker compose exec php ls -ld storage
ここで初めて気付きました。
確認すべきなのは、
- Laravelが誰として動いているか
- storageの所有者は誰か
の2点だったのです。
Permission denied が起きる仕組み
例えば、
Laravel
↓
www-data として実行
なのに、
storage の所有者
↓
別のユーザー
になっていると、Linuxは書き込みを拒否します。
www-data
「storageに書き込みたいです」
Linux
「そのファイルはあなたのものではありません」
結果として、
Permission denied
になります。
今回の学び
今回理解できたのは、
「Permission denied が出たら chown を実行する」
ではなく、
「誰が動いていて、誰がそのファイルを所有しているのかを確認する」
ことが重要だということです。
これからは権限エラーが出たとき、まず次のような確認をしようと思います。
docker compose exec php whoami
docker compose exec php ls -ld storage
docker compose exec php ls -ld bootstrap/cache
まとめ
以前の私は、
Permission denied
↓
とりあえず chown
でした。
今は、
Permission denied
↓
Laravelは誰として動いている？
↓
対象ディレクトリの所有者は誰？
↓
そこにズレはある？
という視点で確認できるようになりました。
同じコマンドを実行する場合でも、「なぜそれが必要なのか」が分かると理解度は大きく変わると感じています。