摘要：問題產生原因最近在使用的時候經常遇到權限問題。如果權限不夠，就會出現問題。從上圖可以看到，主進程的擁有者是，可以讀寫任何文件，權限肯定沒問題。要解決這個問題，其實就是讓用戶有權讀寫以及其中的文件。

最近在使用docker的時候經常遇到權限問題。
通過這個stackoverflow回答，我明白了問題出現的主要原因：Docker在進行bind mount的時候，或者在進行COPY的時候，會保持文件的權限比特位（比如755）、owner ID（比如1000）、group ID（比如1000）與宿主機器上的來源文件相同。而【docker容器主進程的owner ID】（比如www-data(33)）往往與【宿主機器上的文件的owner ID】（比如xiaoming(1000)）不一樣。如果【docker容器主進程的owner】沒有權限讀/寫這個文件，那么bind-mounts和COPY到容器內的文件就不會產生我們預想的效果（比如配置文件無法被容器進程讀取、寫入）。

如果沒有時間查看下面的最佳解決方案，可以試試這個簡單粗暴的解決方案：在宿主機器上，通過sudo chmod -R 777 /path/to/dir將被掛載的目錄的權限比特位設為777。這樣，這個目錄就能被任何用戶讀寫，包括【docker容器主進程的owner】。但是這個方法可能會造成安全隱患，另外，git會將權限改動也視為文件變動（需要設置一下git來解決）。

使用上一篇博客介紹的查看信息命令，在宿主機器上，檢查被bind-mount或者被COPY的文件的權限信息：權限比特位（比如755）、owner ID（比如1000）、group ID（比如1000）。

通過以下命令，在指定容器內運行一個bash：

docker exec -it container_name /bin/bash

進入容器的bash以后，你就可以再次使用上一篇博客的查看信息命令，來查看容器中的進程、文件、用戶信息了:

你可以驗證一下被bind-mount、COPY的文件，它們的權限信息是否與宿主上的相同：權限比特位、owner ID、group ID。

然后，你應該通過ps aux來查看【容器主進程】的owner用戶是誰（如果沒有ps命令的話按照上一篇博客的指示來安裝），這個owner就是需要訪問文件的用戶，這個用戶的權限決定了這個進程是否有權訪問【我們bind-mount、COPY到容器中的文件】。如果權限不夠，就會出現問題。

從上圖可以看到，主進程的擁有者是root，root可以讀寫任何文件，權限肯定沒問題。但是主進程還創建了兩個子進程，擁有者是www-data，這個用戶有可能無法讀寫【被bind-mount或者COPY到容器內的文件】！

因此，現在我們需要檢查www-data是否存在權限不足的問題，首先通過id username來查看這個用戶的 user id、primary group id、加入的所有群組 的信息：

然后，使用stat或者ls -na命令，查看【被bind-mount或者COPY到容器內的文件】的權限信息：

上圖的/codeigniter文件夾是我通過bind-mount掛載到容器內的。可以看到這個文件夾以及其中的文件的ownerId:groupId都是1000:1000，而www-data的ownerId:groupId是33:33。再結合這些文件的權限信息（比如-rw-rw-r--、drwx------），www-data只能讀取其中一些文件，無法寫入任何文件，/codeigniter/application/這個文件夾內的內容連訪問都不行！

如上圖，用stat也能看到同樣的文件信息，只不過一次只能看到一個文件或文件夾的信息。

【容器主進程】有可能會創建其他的進程一起工作（比如上面的例子），如果是這樣的話，你需要檢查所有子進程都有權訪問自己所需的文件。

上面的例子中，/codeigniter以及其中內容的權限比特位、owner ID、group ID都與我的宿主機器上的codeigniter文件夾相同（我登陸ubuntu的賬戶的userid就是1000）！保持文件的元數據(filesystem metadata)是docker的一個特點，也是一個坑點。

既然知道了問題的成因，那么我們就可以想辦法解決它了。
要解決這個問題，其實就是讓www-data用戶有權讀寫/codeigniter以及其中的文件。

有兩個思路：

改變www-data的uid和gid，從33:33變成1000:1000。這樣www-data就是這些文件的owner了，自然就有需要的權限了。改變uid和gid可以通過我上篇文章介紹的usermod命令。具體來說，就是在Dockerfile中加入這樣一句：RUN usermod -u 1000 www-data && usermod -G 1000 www-data。（其實不需要改gid的，改uid就可以成為owner了）

改變容器內/codeigniter的權限信息，使得www-data(33:33)有權讀寫它：

通過chmod命令，在宿主機器上改變codeigniter文件夾的權限比特為777。這樣，在bind-mount到容器里面以后它的權限也是777，因此任何用戶都可以讀寫它的內容。這個方法要求修改開發環境，不太優雅。

在構建image時，將所有需要的文件COPY到鏡像內，然后通過Run chmod 777 -R /codeigniter使得www-data獲得讀寫權限，或者Run chown www-data:www-data -R /codeigniter使得www-data成為owner。

實際上COPY --chown=www-data:www-data ./codeigniter /codeigniter/就能一步將【被COPY的文件】的owner設置為容器內的某個用戶。

我認為Run chmod 777 -R /codeigniter這個解決方案是最方便省事的。

但是我不太想chmod 777，我采用的是COPY --chown=www-data:www-data ./codeigniter /codeigniter/的方案，我喜歡這種方案，因為它只做恰到好處的修改，不多不少。要用好這個方案，我們需要知道被COPY的文件會被哪些進程訪問、這些進程的onwer分別是誰。

使用這個方案以后的結果：


www-data用戶的進程可以讀寫這些文件了！