使用蜗牛星际的朋友，大多数应该都是用其自带的一块杂牌小容量SSD作为系统盘，性能低且容易坏。我是在这块16G的SSD上安装了Openmediavault系统，并启用了Docker容器。前几天系统告警，查看发现SSD空间已经满了，最终确定是下载的docker镜像占用了大量空间。
请看下图，默认情况下，docker的工作目录是/var/lib/docker，下载的镜像、运行时的数据都存储在这里，时间越长，占用空间越大。
那块16G SSD的性能也让人不忍直视，docker跑在上面能运行到现在没出问题，大概我人品不错。立即动手，将目录设置到挂载的其他硬盘上。
迁移docker目录到其他硬盘，网上有教程，结合OMV自身特点，大致是这个流程：
- 停docker服务
- SSH上去，复制/var/lib/docker目录到其他地方
- 在OMV的界面上设置目录到新地方，或者参考网上教程直接改docker的配置文件，都是一样的。
这里注意一个巨坑，很多教程都没有提到这一点！！！
在第二步复制数据时，一定要带上权限复制，如果使用了cp命令，就要加-p参数！
我就因为参考了没有提到这一点的教程，复制后有几个容器运行起来没问题，但MySQL容器启动失败，查看MySQL日志发现是启动时的某些目录或文件没有权限写入造成的。我拷贝后的文件，都是root用户所有，其他用户没有写入权。经查，网上也有人踩过这个坑。。。
本来很简单，只要删除新目录，重新带上权限拷贝一次就应该能解决了，然而我脑子发昏，删除的时候竟然把源/var/lib/docker给删除了！！！
这下好了，只能死马当活马医，在缺少权限信息的新目录上试着挽救一下了。有网友提供的方法非常简单，就是把目录中的overlay2子目录整个权限都设置成可写就行了，但我感觉这太简单太粗暴不符合我的风格，于是以研究Docker存储结构的名号自我安慰，开始手工设置权限。
以前只知道Docker的数据是分层处理的，这次通过学习研究，终于知道这个分层是通过overlay2下面的链式目录实现的，每层目录中的diff子目录，就记录了该层相对于下层数据的变动，具体分析这里就不展开了。
总之，最终我在每个overlay2下面层级的diff子目录中，找到跟mysql容器启动日志中记录的无权限目录，把该目录设置成777权限而解决的（怎么找到这些目录的呢？我用了最笨的方法，每个diff目录都打开看是不是含有mysql报错的目录或文件，幸亏我的容器实例不多！）。因为/var/lib/docker目录已经被我删掉，无从得知这些目录本来应该是什么权限，从进程看，容器中的mysql服务是以openmediavault-webgui用户身份运行的（为毛是这个？？？），而其他的容器中程序是root身份运行的，这就是只有mysql启动失败的原因。最终我还是偷了一点懒，没有修改目录或文件的用户身份，而是用chmod 777搞定。
漫长的手工处理过程，终于一切恢复正常。
为自己的失误而警醒，如果在生产环境那是不是要跑路了？
同时也感谢这次失误，让我对docker的数据存储方式有了初步了解，可谓塞翁失马焉知非福。碰上问题，不逃避绕开、不粗暴解决，而是借机深入研究一番，把失误变成经验，也算是好事一件。
mysql进程的启动用户身份还是有点奇怪，为什么会是openmediavault-webgui呢？累了，不想动了，以后再说吧...
