不到幾天前，其中一台伺服器決定將docker儲存（docker儲存所有容器和映像檔的目錄）移至一個單獨的部分，這
擁有更大的能力。 這項任務看似微不足道，但並不預示著會有麻煩…
讓我們開始吧：
1. 停止並殺死我們應用程式的所有容器：
docker-compose down如果有很多容器並且它們具有不同的成分，您可以這樣做：
docker rm -f $(docker ps -q)2.停止docker守護程式：
systemctl stop docker3. 將目錄移動到所需位置：
cp -r /var/lib/docker /docker/data/storage4. 我們告訴 docker 守護程式在新目錄中尋找。 有幾個選項：要麼使用 -g 標誌將守護程式指向新路徑，要麼使用我們使用的 systemd 配置。 或一個符號連結。 這個我就不詳細說了，網路上都有。 有關將 docker root 移至新位置的手冊。
5. 啟動 docker 守護程式並確保它位於正確的位置：
systemctl status docker在輸出行之一我們應該看到：
├─19493 /usr/bin/dockerd --data-root=/docker/data/storage我們確保該選項已傳遞給守護進程，現在讓我們檢查它是否應用了它（謝謝 )!
docker info | awk '/Root Dir/ {print $NF}' 6. 讓我們開始我們的應用程式：
docker-compose up -d7.檢查
有趣的事情開始了，DBMS、MQ，一切都很好！ 資料庫完好無損，一切正常......除了 nginx。 我們有自己的 nginx，使用 Kerberos 和妓女建構。 查看容器日誌表明它無法寫入 /var/tmp - 權限被拒絕。 我用手指揉著太陽穴，試著分析情況……這怎麼可能？ Docker 映像沒有改變。 我們剛剛移動了目錄。 它總是有效，這是給你的......為了實驗，我用手進入容器並更改了該目錄的權限，有 根，根 755，給了 根，根 777。 一切都開始了……一個想法開始在我的腦海中響起——某種胡言亂語……我想，好吧，也許我沒有考慮到一些事情……
我決定我們愛上了傳輸過程中檔案的存取權限。 我們停止了應用程式、docker 守護進程，刪除了新目錄並使用複製了 /var/lib/docker 目錄 rsync -a.
我想現在一切都很好了，讓我們提升Docker應用程式吧。
啊啊……問題依然存在……我的眼睛抽搐了。 我衝到虛擬機器的控制台，在那裡運行各種測試，我有這個 nginx 映像，我爬到容器內部，這裡 /var/tmp 目錄的權限是 root，root 777。就像我必須手動設定一樣。 但影像是相同的！
xfs 檔案系統隨處可見。
我使用命令進行比較
docker inspect my-nginx:12345所有哈希值都是相同的，都是一對一的。 在伺服器和我的虛擬機器上。 我刪除了本機 nginx 映像並再次從註冊表中提取它，由於多種原因，該映像位於同一台電腦上。 問題是一樣的......現在我的第二隻眼睛在抽搐。
我已經不記得腦子裡在想什麼了，除了喊「啊啊啊啊」之類的。 凌晨4點，透過Docker原始碼了解了鏡像層哈希的原理。 打開第三罐能量飲料。 最後我意識到散列只考慮文件及其內容，但是 沒有訪問權！ 也就是說，我們的權利以某種神秘的方式丟失了，selinux 被禁用，acl 不被使用，並且沒有粘性位。
我刪除了本機映像，也從docker註冊表中刪除了該映像並再次推送。 一切順利。 事實證明，在傳輸過程中，本機映像和註冊表中的映像內部的權利都遺失了。 正如我已經說過的，由於多種原因，它位於同一輛車上。 結果，在一個目錄 /var/lib/docker.
並預期他們是否試圖將碼頭工人的目光返回到舊目錄的問題 - 不，他們沒有嘗試，唉，環境不允許。 是的，我真的很想弄清楚。
寫完這篇文章後，問題的解決方案對我來說似乎是顯而易見的，但在分析時似乎並非如此。 老實說，我谷歌了一下，也沒有發現類似的情況。
結果：問題解決了，還是不懂原因=(
如果有人知道、猜測、了解這個問題的可能原因，我將非常高興在評論中收到您的來信！
來源： www.habr.com