'Table tabDefaultValue doesn't exist' on bench new-site: Finding the Real Frappe Cause

You run bench new-site, it churns for a while, and then it dies complaining that a table called tabDefaultValue does not exist. So you go looking for tabDefaultValue. You search the forum for it, you wonder what a DefaultValue is, you consider whether you need to create it by hand. Every one of those instincts is a dead end, because the table the error names has almost nothing to do with why the install failed.

Here is the thesis: tabDefaultValue is not the problem, it is the messenger. DefaultValue is one of the very first DocTypes Frappe tries to create when it builds a fresh site's schema. If anything went wrong slightly earlier in the install, the database schema import stops, and the next thing Frappe touches after that is tabDefaultValue, which now does not exist because the import never got that far. The real failure already happened. It is sitting in the MariaDB error log, not in bench's output.

So the fix is not to chase the table. It is to read the log that tells you what actually broke: a permissions problem, a MariaDB config or version incompatibility, or a full disk. Let me show you how to find the true cause and clean up the half-built site it left behind.

The exact error

The message takes one of these shapes, with a random hash prefix that is your new site's database name:

pymysql.err.ProgrammingError: (1146, "Table 'tabDefaultValue' doesn't exist")

(1146, "Table '_a1b2c3d4e5f6.tabDefaultValue' doesn't exist")

You may also see it phrased as Table 'tabDefaultValue' missing when it happens during a restore. In every case the number 1146 means "the table you asked for is not there," which is true and useless. The table is not there because the process that was supposed to create it stopped.

Why this happens: the schema import stopped before DefaultValue

When bench new-site runs, it creates an empty database, then imports the Frappe framework's core schema into it, one DocType at a time. DefaultValue is near the front of that queue. If an earlier statement in the import fails, MariaDB aborts that statement, Frappe moves on assuming success, and the very next operation that reads tabDefaultValue throws 1146. The table you see named is simply the first casualty after the real break.

There are four things that commonly break the import, and none of them mention DefaultValue:

Root cause	What you'll see in the MariaDB log
DB user lacks privileges	Access denied or a failed CREATE/ALTER for the site DB
Wrong charset/collation config	Errors creating utf8mb4 tables, or index length failures
MariaDB version incompatibility (11.x)	InnoDB refuses to write tables with ROW_FORMAT=COMPRESSED and an untested-version warning from bench
Disk full	Error writing file, No space left on device, aborted ALTER

The fix, step by step

Step 1: Watch the MariaDB error log while bench runs

This is the single most important step and the one people skip. Open a second terminal and tail the database log, then trigger the install in the first:

# terminal 1
sudo tail -f /var/log/mysql/error.log
# on some distros: /var/log/mariadb/mariadb.log

# terminal 2
bench new-site mysite.localhost

Watch terminal 1 at the exact moment bench fails. The real error, the one that caused everything downstream, appears here. Whatever MariaDB prints in that window is your actual bug. The rest of this article is just the four things it usually is.

Step 2: Confirm the database user's privileges

Frappe creates a dedicated DB user per site and needs it to have full rights on that site's database. If the MariaDB root credentials bench used cannot grant those rights, or the grant silently failed, the schema import cannot create tables. Log into MariaDB as root and check:

SHOW GRANTS FOR '_a1b2c3d4e5f6'@'localhost';

You want to see GRANT ALL PRIVILEGES ON `_a1b2c3d4e5f6`.*. If it is missing or narrower, grant it:

GRANT ALL PRIVILEGES ON `_a1b2c3d4e5f6`.* TO '_a1b2c3d4e5f6'@'localhost';
FLUSH PRIVILEGES;

If bench itself cannot connect as root to do this, the deeper issue is your mariadb_root_password or the root user's host binding, which is a different but related install snag. The general pattern of using Frappe against a managed database, where grants work differently, is covered in Using Frappe / ERPNext with any DBaaS.

Step 3: Fix the MariaDB charset and collation config

Frappe requires the server to default to utf8mb4 with utf8mb4_unicode_ci collation. If your MariaDB is set to latin1 or utf8mb3, table creation for the framework schema fails partway. Add a config drop-in and restart:

# /etc/mysql/mariadb.conf.d/99-frappe.cnf
[mysqld]
character-set-client-handshake = FALSE
character-set-server = utf8mb4
collation-server = utf8mb4_unicode_ci

[mysql]
default-character-set = utf8mb4

sudo systemctl restart mariadb

Confirm it took effect:

SHOW VARIABLES LIKE 'character_set_server';
SHOW VARIABLES LIKE 'collation_server';

Expected: utf8mb4 and utf8mb4_unicode_ci respectively. This one config file resolves a large share of these failures on freshly installed database servers.

Step 4: Check your MariaDB version, especially 11.x

Frappe supports a specific range of MariaDB, and newer releases such as 11.4 are ahead of what a given Frappe version has been tested against. Bench prints a warning to that effect during install (that the MariaDB version is above the tested ceiling), and on some 11.x setups the import fails with an InnoDB error about refusing to write tables with ROW_FORMAT=COMPRESSED. Check your version:

mariadb --version

If you are on 11.x and hitting the InnoDB row-format error, the cleanest path is to install a MariaDB version your Frappe release officially supports rather than fighting the config. For the version currently recommended for ERPNext v15, my step-by-step is in How to Install ERPNext Version 15 in Ubuntu 24.04, and the standalone MariaDB install is in How To Install MariaDB on Ubuntu.

Step 5: Check disk space, then recreate the site cleanly

A full disk aborts writes mid-import and produces exactly this symptom. Check before you retry:

df -h /var/lib/mysql

If the filesystem holding /var/lib/mysql is at or near 100 percent, free space first. Then, because a failed bench new-site leaves a half-built database and a stub site directory behind, remove both before retrying so you are not importing on top of partial state:

bench drop-site mysite.localhost --force --no-backup
# if the DB user/db still linger, drop them as root:
#   DROP DATABASE `_a1b2c3d4e5f6`;
#   DROP USER '_a1b2c3d4e5f6'@'localhost';
bench new-site mysite.localhost

Verification

A site that built correctly answers a bench query without a 1146 in sight. After the install succeeds, confirm the framework schema is fully present:

bench --site mysite.localhost execute frappe.db.get_default --args "['country']"

If that runs without a missing-table error, tabDefaultValue exists and the import completed. You can also list the site's tables directly and confirm the count is in the hundreds, not a handful:

bench --site mysite.localhost mariadb -e "SHOW TABLES;" | wc -l

Expected: several hundred tab* tables for a bare Frappe site, more once ERPNext is installed. A result of only a few tables means the import stopped early again, and you go back to Step 1 and read the log.

What people get wrong

Trying to create tabDefaultValue by hand. You will find forum posts suggesting you manually create the table or copy it from another site. Do not. Even if you do, the hundreds of other tables from the aborted import are still missing, and you have papered over one symptom of a schema that never finished. Fix the cause and rebuild.

Re-running bench new-site repeatedly without cleaning up. Each failed attempt can leave a partial database. Retrying on top of it changes the error but not the outcome. Always bench drop-site (or drop the database) between attempts so each try starts clean.

Assuming it must be a bench bug. This error is almost never a defect in bench or Frappe. It is the environment: privileges, MariaDB config, version, or disk. Reading the MariaDB log settles it in under a minute, which is faster than any forum thread.

When it is still broken

If the MariaDB log shows nothing obvious and all four causes check out, look at two more things. First, SELinux or AppArmor can block MariaDB from writing to a non-default data directory, which produces write failures that look like disk or permission errors; check the audit log. Second, on a container or VM restored from a snapshot, the MariaDB data directory may be in an inconsistent state, in which case a clean database reinitialisation is faster than debugging it. For a broader look at the install path from scratch, including the service ordering that trips people up, the ERPNext 15 install guide linked above walks the whole sequence. Bench's own reference for the command is in the Frappe bench new-site docs.