Nextcloud migration to docker container and MySQL/MariaDB 'Access denied'

I’m attempting to migrate my Nextcloud 29 instance to a new server. Previously, it was running on a bare LAMP stack on Ubuntu 18.04, with PHP 8.2 and MySQL 8. The new setup uses Docker with this .yml file:

version: '3'
services:
  php-apache:
    build:
      context: ./php-apache
    restart: unless-stopped
    depends_on:
      - sql-db
    ports:
      - "${SITE_PORT}:80"
    volumes:
      - ./html:/var/www/html:rw
      - /media/cloud/data/nextcloud-data:/var/www/nextcloud-data:rw
      - ./htmllogs:/var/log/apache2:rw
      - ./php-fpm-www.conf:/usr/local/etc/php-fpm.d/www.conf:ro
    links:
      - sql-db
    environment:
      - "MYSQL_USER: ${MYSQL_USER}"
      - "MYSQL_PASSWORD: ${MYSQL_PASSWORD}"
      - "MYSQL_DATABASE: ${MYSQL_DATABASE}"
      - "LAMP_UID=${LAMP_UID}"
      - "LAMP_GID=${LAMP_GID}"
    networks:
      - www-network

  sql-db:
    image: "mysql:8.4"
    restart: unless-stopped
    ports:
      - ${SQL_PORT}:3306
    volumes:
      - ./sql:/var/lib/mysql
    environment:
      MYSQL_ROOT_PASSWORD: "${MYSQL_ROOT_PASSWORD}"
      MYSQL_USER: "${MYSQL_USER}"
      MYSQL_PASSWORD: "${MYSQL_PASSWORD}"
      MYSQL_DATABASE: "${MYSQL_DATABASE}"
    networks:
      - www-network

networks:
  www-network:
    name: www-network
    driver: bridge

and the Dockerfile for the php container context is:

FROM php:8.2-apache

ADD https://github.com/mlocati/docker-php-extension-installer/releases/latest/download/install-php-extensions /usr/local/bin/

RUN chmod +x /usr/local/bin/install-php-extensions && \
    install-php-extensions pdo pdo_mysql gd imagick zip intl xdebug && \
    a2enmod rewrite

I’ve restored the db from my backup into the new container, restored the nextcloud files and data, adjusted my config.php as following:

<?php
$CONFIG = array (
  'instanceid' => 'XXX',
  'passwordsalt' => 'XXX',
  'secret' => 'XXX',
  'trusted_domains' => 
  array (
    0 => 'XXX',
  ),
  'trusted_proxies' => 
  array (
    0 => 'XXX',
  ),
  'datadirectory' => '/var/www/nextcloud-data',
  'overwrite.cli.url' => 'XXX',
  'dbtype' => 'mysql',
  'dbname' => 'nextcloud',
  'dbhost' => 'sql-db',
  'dbport' => '3306',
  'dbuser' => 'nc',
  'dbpassword' => 'XXX',
  'dbtableprefix' => 'oc_',
  'mysql.utf8mb4' => true,
  'installed' => true,
  'maintenance_window_start' => 5,
  'app_install_overwrite' => 
  array (
    0 => 'occweb',
  ),
  'default_phone_region' => 'US',
  'htaccess.RewriteBase' => '/',
  'maintenance' => true,
  'theme' => '',
  'loglevel' => 0,
  'defaultapp' => '',
);

Now when I either navigate to the server in a browser or run php occ from within the container, I get this:

An unhandled exception has been thrown:
Doctrine\DBAL\Exception:
    Failed to connect to the database: An exception occurred in the driver:
    SQLSTATE[HY000] [1045] Access denied for user 'nc'@'localhost' (using password: YES)
    in /home/www-docker/sites/XXX/lib/private/DB/Connection.php:163

(newlines and indent added for readability)

My troubleshooting steps:

I wrote this test.php file that succeeds, whether browsed to or invoked from within the container, with values pasted straight out of the nextcloud config file:

<?php

try{
	$dbh = new pdo( 'mysql:host=sql-db:3306;dbname=nextcloud',
		'nc',
		'XXX',
		array(PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION));
	$sql = "select uid from oc_users where uid='admin';";
	foreach ($dbh->query($sql) as $row) {
		echo json_encode($row)."\n";
	}
	die(json_encode(array('outcome' => true)));
}
catch(PDOException $ex){
	die(json_encode(array('outcome' => false, 'message' => 'Unable to connect')));
}

I have also swapped (and reloaded) the SQL database between both MySQL and MariaDB.

I have even gone so far as to attempt to restore this to a bare LAMP stack on Ubuntu 24.04, all with this same outcome, Access denied from nextcloud, but success from my test.php, so it really doesn’t seem like my docker setup is the issue.

Is there something persisting perhaps in my nextcloud directory that is overriding my credentials? Why would a test script in the exact same context succeed where nextcloud does not?

Everything about this screams “duh, bad credentials”, but I’m just not seeing it.

This is cross-posted from serverfault:

I guess you’re manually installing Nextcloud within a container based on the PHP Apache-based image? I don’t see where you’re installing Nextcloud within your Dockerfile. So it sort of depends on how you’re doing the install. :slight_smile:

In the official Nextcloud micro-services image there are multiple config files. So this comes up there a lot: you can check your real (merged) config by running occ config:list system within the container (with the option --private if you want to see the credentials).

I also notice that somehow your config.php has dropped the version variable.

P.S. Unrelated, but I’m a bit confused how you’re using fpm with the apache labeled image (which is not fpm based). There are already fpm-based tags for PHP’s images: docs/php/README.md at master · docker-library/docs · GitHub

P.P.S. The Nextcloud micro-services Docker image (GitHub - nextcloud/docker: ⛴ Docker image of Nextcloud) is a pre-built Nextcloud image built on top of the same PHP image sets you’re using as your base. You may find it of interest or inspiration.

1 Like

This is good info. A blocking issue is that invoking php occ *anything* throws this same “Access denied” error. So it seems like even occ attempts to connect to the database before responding to the command.

Regarding the version param, I might have scrubbed that out when I was cleaning up my post here. It’s in the actual file with the value of 29.0.4.1

P.S. you can ignore the fpm stuff, I’ve been throwing stuff at the wall for about 24 hours now.

P.P.S. I’m interested in the docker image. Is it possible that attaching the image to my database (assuming it’s not the database that’s at fault) and would retain my users/configs/etc. without having to start from scratch?

Oh, yeah, I kind of spaced you’ve have that obstacle since this is db related and not about other config parameters. Oops!

Do you have any files in config/ other than config.php? Even a backup file there can get picked and merged into the full config. That’s a common culprit.

So turns out this is a case of Grade A, top-shelf PEBKAC. I’m not gonna say it was a doubled up character in the db password… but I’m not NOT gonna say it either. I could explain how this escaped my notice for 36 hours, but in the end, it’s a dumb mistake as old as time.

Thanks for the help, I did learn some good stuff. Chiefly the segmented overrides for config, which is pretty cool.

2 Likes

This topic was automatically closed 8 days after the last reply. New replies are no longer allowed.