不到几天前，其中一台服务器决定将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.
并预期他们是否试图将码头工人的目光返回到旧目录的问题 - 不，他们没有尝试，唉，环境不允许。 是的，我真的很想弄清楚。
写完这篇文章后，问题的解决方案对我来说似乎是显而易见的，但在分析时却似乎并非如此。 老实说，我谷歌了一下，没有发现类似的情况。
结果：问题解决了，还是不明白原因=(
如果有人知道、猜测、了解这个问题的可能原因，我将非常高兴在评论中收到您的来信！
来源： habr.com