Dockerコンテナにホストディレクトリへの書き込み権限がない場合の解決策

Docker コンテナを適用する場合、多くの場合、ホストディレクトリを Docker コンテナにマウントします。

ホストマシンのフォルダー権限がルートに属している場合は、ディレクトリの内容が正常に書き込まれるように、フォルダー権限ユーザーを chown に設定する必要があります。

次に例を示します。

jenkinsのdockerバージョンを使用します。実行後、次のエラーが発生します。

[root@localhost CICD]# docker logs -f jenkins 
touch: '/var/jenkins_home/copy_reference_file.log' にアクセスできません: 権限が拒否されました
/var/jenkins_home/copy_reference_file.log に書き込めません。ボリュームの権限が間違っていますか?

私のjenkinsがマウントされているディレクトリは/opt/jenkins/xxxxxで、rootユーザーによって作成され、jenkinsユーザーのuidは1000です。

したがって、次のように設定を chown する必要があります。

sudo chown -R 1000:1000 /opt/jenkins

その後、コンテナを再起動するとエラーは解消されます。

補足: Docker コンテナからボリュームを書き込むときにファイル権限を処理する 2 つの方法を紹介します。

事前に言っておく

コンテナは、ネイティブインストールツールの代わりとしてよく使用されます。古いツールを使用するよりも、ホスト上で必要なバージョンのコンテナを使用する方がはるかに優れています。ただし、コンテナーがホストシステムと対話するたびに、ファイルのアクセス許可が不正確または破損したままになります。

幸いなことに、この問題の解決にはスクリプトを使用する必要はありません。

問題の説明

コンテナがローカルディレクトリをマウントし、そこにファイルを書き込む場合、その所有権はコンテナ内のユーザーによって決定されます。

nicholas@host:~/source$ mkdir source
nicholas@host:~/source$ docker run -it --rm --volume $(pwd):/source --workdir /source ubuntu
root@a031d11c9515:/source# mkdir サブディレクトリ
root@a031d11c9515:/source# touch サブディレクトリ/新しいファイル
root@a031d11c9515:/source# 終了
出口
ニコラス@ホスト:~/source$ ls -lR
.:
合計 4
drwxr-xr-x 2 ルート ルート 4096 7月16日 19:35 サブディレクトリ
 
./サブディレクトリ:
合計 0
-rw-r--r-- 1 ルート ルート 0 7月16日 19:35 新しいファイル
nicholas@host:~/source$ rm -rf サブディレクトリ/
rm: 'subdir/newfile' を削除できません: 権限が拒否されました

さらに、所有権が正しくないディレクトリやファイルは削除できない場合があります。

解決策1: 容器から取り出す

非常に一般的な解決策は、コンテナ内からファイルとディレクトリの所有権を変更することです。

nicholas@host:~/source$ docker run -it --rm --volume $(pwd):/source --workdir /source ubuntu
ルート@d1c3bee8bb2b:/source# ls -al
合計 12
drwxrwxr-x 3 1000 1004 4096 7月16日 19:35 .
drwxr-xr-x 1 ルート ルート 4096 7月16日 19:39 ..
drwxr-xr-x 2 ルート ルート 4096 7月16日 19:35 サブディレクトリ
root@d1c3bee8bb2b:/source# chown 1000:1000 サブディレクトリ/ -R
ルート@d1c3bee8bb2b:/source# ls -l
合計 4
drwxr-xr-x 2 1000 1000 4096 7月16日 19:35 サブディレクトリ
root@d1c3bee8bb2b:/source# 終了
出口
ニコラス@ホスト:~/source$ ls -l
合計 4
drwxr-xr-x 2 ニコラス lpadmin 4096 7月 16 19:35 サブディレクトリ
ニコラス@ホスト:~/source$

このアプローチの欠点は、追加のロジックが必要であり、コンテナを実行しているユーザーのユーザー ID とグループ ID を知る必要があることです。

解決策2: 正しい所有権を持つファイルを作成する

2 番目のソリューションはよりクリーンで、コンテナー内に正しい所有権を持つファイルとディレクトリを作成します。 Docker は、コンテナ内のユーザーのユーザー ID とグループ ID を設定するためのパラメータを提供します。

nicholas@host:~/source$ docker run -it --rm --volume $(pwd):/source --workdir /source --user $(id -u):$(id -g) ubuntu
グループ: グループ ID 1004 の名前が見つかりません
名前がありません!@bf7f355f3b65:/source$ touch newfile
名前がない！@bf7f355f3b65:/source$ exit
出口
ニコラス@ホスト:~/source$ ls -l
合計 4
-rw-r--r-- 1 ニコラス ニコラス 0 7月16日 19:42 newfile
drwxr-xr-x 2 ニコラス lpadmin 4096 7月 16 19:35 サブディレクトリ
ニコラス@ホスト:~/source$

この方法は、ユーザー ID およびグループ ID エラーを解決するのに役立ちます。

セキュリティ上の理由から、コンテナ内で root として実行することは最悪の方法であることに注意してください。 Dockerfile では、ルート権限を直接使用しないようにするために、常に USER ディレクティブを使用する必要があります。

上記は私の個人的な経験です。参考になれば幸いです。また、123WORDPRESS.COM を応援していただければ幸いです。間違いや不備な点がありましたら、遠慮なくご指摘ください。

以下もご興味があるかもしれません: