web-dev-qa-db-ja.com

Dockerコンテナが「Permission denied」というプロンプトを表示するのはなぜですか？

次のコマンドを使用してdockerコンテナーを実行し、Host（/root/database）からcontainer（/tmp/install/database）にディレクトリをマップします。

# docker run -it --name Oracle_install -v /root/database:/tmp/install/database bofm/Oracle12c:preinstall bash

しかし、コンテナ内では、lsを使用して/tmp/install/database/のコンテンツを一覧表示することはできませんが、私はrootであり、すべての権限を持っています。

[root@77eb235aceac /]# cd /tmp/install/database/
[root@77eb235aceac database]# ls
ls: cannot open directory .: Permission denied
[root@77eb235aceac database]# id
uid=0(root) gid=0(root) groups=0(root)
[root@77eb235aceac database]# cd ..
[root@77eb235aceac install]# ls -alt
......
drwxr-xr-x. 7 root root  4096 Jul  7  2014 database

Hostで/root/databaseを確認しますが、すべて問題ありません。

[root@localhost ~]# ls -lt
......
drwxr-xr-x.  7 root root       4096 Jul  7  2014 database

Dockerコンテナが「Permission denied」というプロンプトを表示するのはなぜですか？

更新：
根本原因はSELinuxに関連しています。実際、昨年は同様の issue に出会いました。

linuxdockerpermissionspermission-denieduser-permissions
11
Nan Xiao

共有ディレクトリのコンテナ内で許可が拒否されたのは、この共有ディレクトリがデバイスに保存されているためです。デフォルトでは、コンテナはどのデバイスにもアクセスできません。オプション$docker run --privilegedを追加すると、コンテナはallデバイスにアクセスし、カーネル呼び出しを実行できます。 これは安全とは見なされません。

デバイスを共有するよりクリーンな方法は、docker run --device=/dev/sdbオプションを使用することです（/dev/sdbが共有するデバイスの場合）。

Manページから：

  --device=[]
      Add a Host device to the container (e.g. --device=/dev/sdc:/dev/xvdc:rwm)

  --privileged=true|false
      Give extended privileges to this container. The default is false.

      By default, Docker containers are “unprivileged” (=false) and cannot, for example, run a Docker daemon inside the Docker container. This is because by default  a  container is not allowed to access any devices. A “privileged” container is given access to all devices.

      When  the  operator  executes  docker run --privileged, Docker will enable access to all devices on the Host as well as set some configuration in AppArmor to allow the container nearly all the same access to the Host as processes running outside of a container on the Host.
6
Auzias

Docker-composeを使用してnfsマウントポイントをボリュームとして共有すると、同様の問題が発生しました。次の方法で問題を解決できました。

    docker-compose up --force-recreate

イベントを発見したとしても、これは他の誰かを助けるかもしれません。

0
d g

別の理由は、UID/GIDとの不一致です。これは多くの場合、マウントをルートとして変更できるが、コンテナユーザーとしては変更できないと表示されます

UIDを設定できるため、ubuntuとして実行されているubuntuコンテナの場合、:uid=1000 （確認する id -u）ユースケースに応じてUIDをローカルに設定します。

uid = valueおよびgid = value

ファイルシステム内のファイルの所有者とグループを設定します（デフォルト：uid = gid = 0）

このtmpfsの例については、このブログをご覧ください。

docker run \
       --rm \
       --read-only \
       --tmpfs=/var/run/prosody:uid=100 \
       -it learning/tmpfs

http://www.dendeer.com/post/docker-tmpfs/

0
KCD