不迟于几天前，决定在其中一台服务器上将docker存储（docker存储所有容器，图像文件的目录）移动到一个单独的分区，该分区
拥有更多的能力。 看起来，这项任务是微不足道的，并且没有预示着麻烦……
入门：
1.停止并终止我们应用程序的所有容器：
docker-compose down
如果有很多容器，并且它们的组成不同，则可以执行以下操作：
docker rm -f $(docker ps -q)
2.停止docker守护程序：
systemctl stop docker
3.将目录移动到所需位置：
cp -r /var/lib/docker /docker/data/storage
4.我们通知docker的恶魔查看新目录。 有几个选项：使用-g标志将守护程序指向新路径，或者使用我们使用的systemd配置。 好吧，还是符号链接。 我不会多说，互联网上有
很多手册将Docker root移植到新位置。
5.我们启动docker恶魔，然后看它应该在哪里：
systemctl status docker
在输出的其中一行中，我们应该看到：
├─19493 /usr/bin/dockerd --data-root=/docker/data/storage
我们确保已将选项传递给守护程序，现在我们
将检查它是否已应用（感谢
inkvizitor68sl ）！
docker info | awk '/Root Dir/ {print $NF}'
6.我们开始应用程序：
docker-compose up -d
7.检查
有趣的开始了，DBMS，MQ一切都很好！ 该基础完好无损，除nginx之外，其他所有功能都适用。 我们有自己的nginx程序集和kerberos
和妓女 。 并且查看容器的日志表明他无法写入/ var / tmp-权限被拒绝。 我用威士忌拉伸手指，然后尝试分析情况……那是什么？ 泊坞窗映像未更改。 我们只是移动了目录。 它一直都有效，这是给您的...为了进行实验，我用笔进入了容器，并更改了该目录的权限，其中有
root（根755） ，
root（根777） 。 一切都开始了……我的脑海里响起了一个念头-一种胡话...我以为，也许我没有考虑到某些东西...
我决定我们喜欢传输过程中对文件的访问权限。 他们停止了应用程序docker守护程序，删除了新目录，并使用
rsync -a复制了/ var / lib / docker目录。
我认为现在一切都很好，我们正在提升docker应用程序。
III ...问题仍然存在...我的眼睛抽搐了。 我冲到虚拟机的控制台，在其中运行各种测试，得到了nginx映像，然后爬入了容器，这里的根777根权限位于/ var / tmp目录中，也就是说，我必须忍受相同的操作。 但是图像是相同的！
到处都使用FS xfs。我通过命令比较
docker inspect my-nginx:12345
所有哈希都是相同的，都是一对一的。 在服务器和我的virtualka上。 我删除了本地nginx映像，并再次使用注册表假脱机，由于多种原因，该注册表位于同一台计算机上。 问题是一样的...现在我的第二只眼睛抽搐了。
除了“ AAAAAAA”的尖叫声和其他东西，我不记得在想什么。 在凌晨4点的大街上，泊坞窗消息源被用来了解哈希图像层的原理。 他打开了第三罐能量。 最后，我突然意识到，哈希仅考虑文件及其内容，而不考虑
访问权限 ！ 也就是说，以某种神秘的方式，权利被击败，并且selinux被禁用，acl不被使用，粘性位不存在。
我删除了本地映像，也从Docker注册表中删除了该映像，然后再次启动它。 而且有效。 事实证明，在传输过程中，在本地映像内和注册表中的映像内，权利都遭到了殴打。 正如我所说，由于多种原因，它位于同一辆车上。 结果是在一个目录/ var / lib / docker中。
并预料到他们是否会尝试将docker的目光恢复到旧目录的问题-不，可惜，情况不允许。 是的，我真的很想弄清楚。
写完这篇文章后，问题的解决方案对我来说似乎很明显，但在分析时似乎并非如此。 老实说，我用谷歌搜索，没有发现类似情况。
底线：我解决了问题，我不明白原因=（
如果有人知道/猜想/对这个问题的可能原因有见识，我将非常高兴见到您在评论中！