web-dev-qa-db-ja.com

Dockerでchmodが正しく機能しない

私はSymfonyアプリのDockerイメージを構築しており、Apacheサーバーにキャッシュおよびログフォルダーへの書き込みを許可する必要があります

#Dockerfile
FROM php:7-Apache

RUN apt-get update \
&& apt-get install -y libicu-dev  freetds-common freetds-bin unixodbc \
&& docker-php-ext-install intl mbstring \
&& a2enmod rewrite

COPY app/php.ini /usr/local/etc/php/
COPY app/Apache2.conf /etc/Apache2/Apache2.conf
COPY ./ /var/www/html

RUN find /var/www/html/ -type d -exec chmod 755 {} \; 
RUN find /var/www/html/ -type f -exec chmod 644 {} \;
RUN chmod -R 777 /var/www/html/app/cache /var/www/html/app/logs

docker build -t myname/symfony_apps:latest .でこのイメージをビルドし、docker run -p 8080:80 myname/symfony_apps:latestでコンテナを実行すると、 Apacheログは、アクセス許可拒否エラーで溢れ、私がls -aで確認した奇妙なことと、アクセス許可は問題ありません。コンテナのbashからchmodを実行すると、Apacheのアクセス許可の問題がなくなり、アプリは正常に動作します

状況

dockerfile：からのchmodコマンドの実行：権限が変更されましたが、Apacheは依然として権限の拒否について不満を述べています。 コンテナー内でbashを使用してchmod同じコマンドを実行：権限が変更され、アプリが実行されています

任意のアイデア、何か不足していますか、Dockerfileのどこかにrootユーザーを追加する必要がありますか？

permissionsdockerchmod
18
storm

同じ問題があり、ディレクトリコンテンツが1つのレイヤーで作成され、そのアクセス許可が他のレイヤーで変更された場合、dockerまたはoverlay2にいくつかのバグがあるようです。

回避策として、ソースを一時ディレクトリにコピーできます。

COPY . /src

次に、それを/var/www/htmlに移動し、（1つのRUNコマンドで）権限を設定します。

RUN rm -rf /var/www/html && mv /src /var/www/html &&\
    find /var/www/html/ -type d -exec chmod 755 {} \; &&\
    find /var/www/html/ -type f -exec chmod 644 {} \; &&\
    chmod -R 777 /var/www/html/app/cache /var/www/html/app/logs

また、私は GitHub issue を作成しました。

15
mixel

DockerでのRUNのデフォルトのシェルは/ bin/shであり、これは実際に正しく設定されていないアクセス許可に問題がある場所です。

しかし、/ bin/bashを使用するように変更して簡単に修正できます。ディレクトリリストの前後に注意してください

Step 7/9 : RUN /bin/bash -c 'ls -la; chmod +x gitlab-properties-builder.sh; ls -la'
---> Running in dc57ae77aa67

drwxr-xr-x. 3 root root      103 Mar  8 17:56 .
drwxr-xr-x. 1 root root       46 Mar  8 17:57 ..
drwxr-xr-x. 2 root root        6 Mar  7 20:47 config
-rw-r--r--. 1 root root     2340 Mar  7 21:20 gitlab-properties-builder.sh
-rw-r--r--. 5 root root 57325770 Mar  5 14:39 gitlab-scm-collector-2.0.5-SNAPSHOT.jar

drwxr-xr-x. 1 root root       42 Mar  8 17:56 .
drwxr-xr-x. 1 root root       61 Mar  8 17:57 ..
drwxr-xr-x. 2 root root        6 Mar  7 20:47 config
-rwxr-xr-x. 1 root root     2340 Mar  7 21:20 gitlab-properties-builder.sh
-rw-r--r--. 5 root root 57325770 Mar  5 14:39 gitlab-scm-collector-2.0.5-SNAPSHOT.jar
---> 8b5de6e348d3
7
Thad Guidry

追加してみてください：

USER root

それは私のために働いた。

5
secavfr

この問題は、上流のDockerfile内のVOLUME定義の結果である可能性があります。ボリュームがDockerfileで定義されている場合、COPYまたはADDコマンドを使用してファイルをイメージに直接追加できます。ただし、RUN行は次のようになります。

  • Dockerfile の現在の時点でのイメージ定義を使用して一時コンテナーを作成します
    • その一時的なコンテナには、あなたまたはDockerfile内で指定された親イメージとして匿名のボリュームがマウントされます
    • 匿名ボリュームは、イメージのコンテンツから初期化されます
  • コマンドはコンテナ内で実行されます
    • このRUNコマンドの実行中にディレクトリを一覧表示すると、適用された変更が表示されますが、それらの変更はボリュームに適用されています
  • Runコマンドが完了すると、Dockerはコンテナへの変更をキャプチャします
    • これらの変更は、一時コンテナを削除しない場合、docker diffで確認できます（--rm=falseを使用してビルドを実行し、それらを残すことができます）
    • これらの変更は、一時的なコンテナーファイルシステム内に存在しないため、ボリュームが個別であるため、匿名ボリュームの内容は含まれません。

この動作のため、次のオプションがあります。

  1. ファイルを別のディレクトリにコピーして、そこのアクセス許可を変更できます
  2. ホストのアクセス許可を修正して、それらのアクセス許可を直接コピーできるようにすることができます
  3. イメージからボリュームを削除するか、アップストリームイメージを取得してボリューム定義を削除するか、ボリューム定義なしでアップストリームイメージの独自のコピーを再構築し、それに基づいてイメージを作成できます。

現在のphp画像内では、ボリュームが削除されているように見えることに注意してください。これは、事実上、オプション3があることを意味しています。

2
BMitch

私は次のことを試してみました：

FROM Alpine

LABEL MAINTAINER="YIMGA YIMGA Salathiel Genèse"
RUN apk add --no-cache inotify-tools
CMD [ "./script.sh" ]
WORKDIR /opt/app/
COPY src/ /opt/app/
RUN chmod a+x *.sh

そして、それはうまく機能します。

しかしながら

Docker-composeボリュームを介してその実行可能ファイルをオーバーライドすると、execute権限は単にロールバックされたようになり、技術的に元のファイル権限にオーバーライドされます。

開発モードの修正は単にchmod a+x yourfile Hostから。これは、構成ボリュームのマウント時に継承されます。

0
Salathiel Genèse