服务器扩容内存后MySQL Docker容器启动权限问题求助

两次报错本质均为容器内mysql用户对目标写入目录无操作权限，大概率是服务器RAM扩容过程中，运维人员调整了宿主机目录权限、容器安全规则或Docker存储配置导致，可按以下步骤排查解决：

• 第一步：校验/var/run/mysqld目录权限
  • 若你的docker-compose配置中已将容器内/var/run/mysqld目录映射到宿主机，先执行chown -R 999:999 宿主机对应映射目录路径，MySQL官方镜像内默认mysql用户的uid为999、gid为999，该命令可直接给对应目录开放写入权限。可临时给目录设777权限验证是否为权限导致的问题，验证通过后再回收权限避免安全风险。
  • 若未映射该目录，可在docker-compose配置中添加启动命令覆盖默认逻辑，先修正容器内目录权限再启动MySQL：

    command: bash -c "chown -R mysql:mysql /var/run/mysqld && docker-entrypoint.sh mysqld"
    

• 第二步：排查宿主机安全模块拦截
  • 若宿主机为CentOS/RHEL系列，先执行getenforce检查SELinux状态，若返回Enforcing，先执行setenforce 0临时关闭SELinux验证问题是否解决，若解决则执行chcon -Rt svirt_sandbox_file_t 所有MySQL映射到宿主机的目录路径给目录配置SELinux访问标签即可。
  • 若宿主机为Debian/Ubuntu系列，执行dmesg | grep -i apparmor | grep -i mysql检查是否有AppArmor拦截记录，若有拦截可临时给容器添加AppArmor豁免规则，或调整系统AppArmor配置。
• 第三步：检查Docker存储配置异常
  • 执行docker info | grep "Docker Root Dir"查看Docker根目录路径，确认扩容过程中未修改该目录权限，正常权限应为root用户、docker用户组所有。
  • 若存在镜像存储层损坏的可能，可删除现有MySQL容器及对应镜像，重新拉取对应版本的MySQL镜像后再启动容器。
• 临时应急恢复方案
  若需要快速恢复服务，可直接修改MySQL启动参数，将Socket文件生成路径改到已经验证过权限正常的/tmp目录下，绕开/var/run/mysqld的权限限制，在docker-compose的command参数中添加：

  command: mysqld --socket=/tmp/mysqld.sock --mysqlx-socket=/tmp/mysqlx.sock
  

内容的提问来源于stack exchange，提问作者dor mordehcai