やろうとしたこと
nginx(openresty)をdockerで起動し、ホストのディレクトリ(nginx.confなどが置いてある)をマウントしようとした。業務だったので、家でのように「とりあえずroot」とやるのは気が引けて色々調べた(結局今はrootになっているが)。
環境
CentOS 7.3
docker 1.13.1
困ったこと
マウント先のファイルの権限を正しく設定してもlsなどでpermission deniedがでて、ファイルが読めない。
結論
- dockerコンテナ内でもuid, gidがホストと同じなら同一ユーザとみなされる
- ただし、SELinuxを知らずにやると権限があるように見えてもpermission deniedされる(今回)
確認したこと
まずは権限が本当にあっているのか確認1。
コンテナ内でuser1(ホストと合わせる)という一般ユーザを作り、user1で色々実行できればいいなと思って調べた。
Dockerfile
FROM openrestyの何か
RUN useradd --disabled-password user1
# USER user1 を試したりも
確認パターン
| ファイル所有者(ホスト側) | コンテナ実行者 | コンテナ内作業 | 結果 | 備考 |
|---|---|---|---|---|
| user1 | root | マウント先ディレクトリでls | Permission denied | まぁわかる |
| root | root | マウント先ディレクトリでls | Permission denied | ホストとコンテナのrootは同じだから本来いけるはず |
| user1 | user1 | - | nginx起動せず(コンテナexit) | nginxのstart権限がないのかも |
| user1 | root |
su user1してからマウント先ディレクトリでls |
Permission denied | 同一ユーザだから2本来行けるはず |
そのほかchmod 777 -R <ディレクトリ>も試しましたが同じですね。
今回の対応
コンテナ実行とかもろもろuser1でやるのは(そもそも起動もしないし)色々大変だろうと判断し3、とりあえずrootでやることに(まず動作確認したい)。
それでもうまくいかずに調べていたら、CentOSなどはデフォルトでSELinuxというものが有効になっており、これが関係しているとのこと。ホスト側でgetenforceコマンドの出力がEnforcingなら有効。有効だったのでこれを一時的に無効にするsudo setenforce 0を実行すると無事コンテナ内でマウント先のファイルが見られた。setenforce 0は一時的で、OS再起動するとリセットされる。
そして当然ながらセキュリティ関連のものを脳筋で無効にするのはいいことではなく、docker公式がSELinuxとの併用を推奨しているとの噂もありました(一次ソースに当たらない人)。
所感
dockerで権限があってるのにマウント先見られなかったらSELinuxを知るとよい。
できればSELinux有効で正しい設定をして今回の問題を解決したいものである。