群晖NAS通过Docker与Portainer部署Nextcloud和MariaDB时出现1045访问拒绝报错求助

• 旧数据卷残留导致初始化逻辑失效
  MariaDB官方镜像的环境变量（包括数据库用户名、密码、库名配置）仅会在/var/lib/mysql数据目录完全为空、完成首次冷启动初始化时执行。如果Docker环境中已经存在同名的mariadb命名卷（来自之前的部署尝试），MariaDB启动时会直接加载旧数据中存储的用户权限规则，不会重新根据当前compose里的环境变量重建用户凭证，此时Nextcloud用新配置的账号密码连接，自然会被拒绝访问。
• 凭证配置不匹配
  Compose中定义的MYSQL_PASSWORD是专门给MYSQL_USER（即nextclouduser）配置的连接密码，和MYSQL_ROOT_PASSWORD对应的root管理员账号密码完全独立。如果在Nextcloud安装页错把root密码填写成nextclouduser的连接凭证，也会触发权限校验失败。
• 旧的用户访问限制规则
  如果之前在MariaDB中手动给nextclouduser配置了绑定特定IP的访问规则，Nextcloud容器每次重建后分配的桥接网络IP会发生变动，一旦不在允许的IP列表内，就会被MariaDB拦截连接请求，和报错中显示的连接来源IP（172.17.0.7）的场景完全匹配。

全新部署场景的标准修复流程 #

• 停止当前所有运行的MariaDB、Nextcloud容器，删除残留的旧mariadb命名卷：通过docker volume ls找到对应compose项目前缀的mariadb卷，执行docker volume rm <卷名>即可，确保MariaDB启动时会执行全新的数据库初始化流程。
• 修正compose配置的兼容问题：
  • 移除错误的版本标识version: '2.9'，当前新版Docker Compose已经不需要手动声明配置版本，原写法属于无效标识，可能导致配置解析时环境变量注入异常
  • 移除已经被淘汰的links配置：Docker Compose默认会为同项目下的服务创建互通的桥接网络，容器间直接通过服务名（即mariadb）即可正常解析通信，手动添加的links不仅没有额外作用，还可能导致网络配置异常
• 重新执行compose启动命令，等待MariaDB容器日志输出ready for connections标识后，再回到Nextcloud安装页填写对应配置：
  • 数据库类型选择MySQL/MariaDB
  • 数据库用户填写nextclouduser
  • 数据库密码填写compose中配置的mysqlpassword
  • 数据库名填写nextcloudatabasename
  • 数据库主机填写mariadb

保留已有数据的临时修复流程 #

不需要删除现有数据卷，直接通过exec命令进入运行中的MariaDB容器，手动重置用户权限配置：

1. 执行命令进入数据库命令行：
   docker exec -it mariadb mysql -uroot -p你配置的MYSQL_ROOT_PASSWORD
2. 依次执行以下SQL语句完成权限重建：

   -- 删除旧的残留用户规则
   DROP USER IF EXISTS 'nextclouduser'@'%';
   -- 重建用户，允许来自Docker内网任意IP的连接
   CREATE USER 'nextclouduser'@'%' IDENTIFIED BY 'mysqlpassword';
   -- 为用户授予对应数据库的全部操作权限
   GRANT ALL PRIVILEGES ON nextcloudatabasename.* TO 'nextclouduser'@'%';
   -- 刷新权限配置使其立即生效
   FLUSH PRIVILEGES;
   

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