# Something bad happened: in create new site

**URL:** https://community.kinsta.com/t/something-bad-happened-in-create-new-site/2190
**Category:** Bug Reports
**Created:** [March 30, 2023, 5:05pm UTC](https://community.kinsta.com/t/something-bad-happened-in-create-new-site/2190 "2023-03-30T17:05:09Z")
**Posts on this page:** 1
**Showing post:** 23

<div class="post-metadata">

### Author: ![dgilfillan](https://sea2.discourse-cdn.com/flex020/user_avatar/community.kinsta.com/dgilfillan/32/1122_2.png) [@dgilfillan](https://community.kinsta.com/u/dgilfillan)
#### Post date: [February 16, 2026, 6:27pm UTC](https://community.kinsta.com/t/something-bad-happened-in-create-new-site/2190/23 "2026-02-16T18:27:11Z")

</div>

Confirming this is still occurring in DevKinsta 2.13.6 and matches the behaviour described earlier in this thread.

On a completely clean install (all containers, volumes, and AppData removed), creating a new site fails with “Something bad happened”.

Observed behaviour:

- DevKinsta creates the `devkinsta_db` container

- `MYSQL_ROOT_PASSWORD=<random>` is visible via `docker inspect`

- DevKinsta attempts DB authentication

- Authentication fails with `ERROR 1045`

- Provisioning aborts before `wp-config.php` is written

As @StormChild described, manually setting the root password inside the container can resolve it in some cases:

```auto
mysql -u root
ALTER USER 'root'@'localhost' IDENTIFIED BY '<password from docker inspect>';
FLUSH PRIVILEGES;

```

However, this is not a failsafe workaround. In some cases (including mine), root cannot be accessed without a password and the DB ends up in a partially initialised state where authentication still fails.

Failsafe workaround (reproducible):

1. Stop and remove the DB container:  
`docker rm -f devkinsta_db`

2. Remove the DB volume:  
`docker volume rm devkinsta_db_data`

3. Recreate the DB container using the password shown in `docker inspect`:

```auto
docker run -d --name devkinsta_db \
  --network devkinsta_network \
  -e MARIADB_ROOT_PASSWORD=<password from inspect> \
  -v devkinsta_db_data:/var/lib/mysql \
  kinsta/devkinsta_db:1.3.6

```

1. Verify authentication works:  
`docker exec -it devkinsta_db mysql -uroot -p<password> -e "SELECT 1;"`

After this clean initialisation, DevKinsta can complete site creation normally.

This strongly suggests a first-run MariaDB initialisation / authentication sequencing issue (race condition) where DevKinsta attempts DB access before the root password is properly applied, leaving the volume in a broken state.

Since this issue has been reported multiple times (2023–2025) and is still reproducible on a clean install, could the DevKinsta team please investigate:

- Adding a proper DB readiness / authentication check before proceeding with provisioning

- Automatically recovering from failed first-run DB initialisation instead of leaving a broken volume

At the moment, manual DB volume removal is the only fully reliable recovery method.

---

_[View the full topic](https://community.kinsta.com/t/something-bad-happened-in-create-new-site/2190)._