You exported a database from a MySQL 8 server — maybe an old VPS, maybe a developer's local Docker setup, maybe a SaaS export tool — and now you're trying to bring it into your cpanel" class="auto-link">wordpress-missing-a-temporary-folder-upload-error" class="auto-link">cPanel account. You open phpMyAdmin, hit Import, pick the .sql file, click Go, and instead of a success message you get a wall of red: Unknown collation: 'utf8mb4_0900_ai_ci'. The file looks fine in a text editor. The database you're importing into exists and has the right privileges. It still won't go in. Here's why that happens on cPanel specifically, and the three ways to fix it depending on how much control you have over the server.

Symptom: Import Stops Dead on a Collation Error

The error usually shows up almost immediately after you click Go, sometimes after only a handful of tables have imported. It reads something like:

#1273 - Unknown collation: 'utf8mb4_0900_ai_ci'

or, if you're importing via SSH instead of the browser:

ERROR 1273 (HY000) at line 42: Unknown collation: 'utf8mb4_0900_ai_ci'

Everything up to that line imports. Everything after it doesn't, and depending on where the error hits, you can end up with a database that's half-populated — some tables present, some missing, foreign keys pointing at nothing. It looks like file corruption. It isn't.

Cause: MariaDB Doesn't Know MySQL 8's Newer Collations

Almost every cPanel server runs MariaDB, not Oracle's MySQL, even though the two are compatible for the vast majority of day-to-day use. Where they diverge is character set collations. MySQL 8.0 introduced a new default collation, utf8mb4_0900_ai_ci, built on Unicode 9.0 case-insensitive accent-insensitive rules. MariaDB has its own long-standing default, utf8mb4_general_ci (or utf8mb4_unicode_ci on newer builds), and simply has no internal definition for the MySQL 8-specific collation name. Some newer MariaDB releases (10.6 and later, depending on the exact point release) added partial recognition or aliasing for a few of MySQL 8's collations, but plenty of cPanel servers — especially ones on CloudLinux with an older MariaDB branch — still don't.

So when a CREATE TABLE or ALTER TABLE statement in the dump says COLLATE=utf8mb4_0900_ai_ci, MariaDB reads a collation name it has no entry for and throws #1273. It's not a permissions issue, not a corrupted file, not a size limit — it's a vocabulary mismatch between two database engines that both call themselves "MySQL-compatible."

This shows up constantly with:

  • Dumps taken from managed MySQL 8 services (some cloud database platforms default to 8.0 with utf8mb4_0900_ai_ci).
  • Docker images running mysql:8 instead of mariadb.
  • Database migration or export tools that hardcode MySQL 8 defaults regardless of the source.
  • Client dumps from developers who don't know or don't mention which engine they're actually running.

Fix: Rewrite the Collation Before You Import

You don't need to touch the actual data, just the collation and charset declarations sitting in the CREATE/ALTER statements. Pick the method that matches what access you have.

Option 1: Fix the File Before Uploading (No SSH Needed)

If you only have cPanel/phpMyAdmin access, open the .sql file in a plain text editor (not Word, not Notepad's default encoding handling — use something that won't mangle UTF-8, like VS Code or Notepad++) and do a find-and-replace across the whole file:

FindReplace with
utf8mb4_0900_ai_ciutf8mb4_unicode_ci
utf8mb4_0900_binutf8mb4_bin

Save, re-upload, re-import. For files under a few dozen megabytes this is the fastest path and doesn't require touching the server at all.

Option 2: Fix It on the Command Line (SSH Access)

For larger dumps, editing in a GUI text editor gets slow or the file won't open cleanly. Use sed instead, which streams through the file without loading the whole thing into memory:

sed -i 's/utf8mb4_0900_ai_ci/utf8mb4_unicode_ci/g; s/utf8mb4_0900_bin/utf8mb4_bin/g' backup.sql

Then import directly with the mysql client, which also sidesteps phpMyAdmin's upload size and execution-time limits entirely:

mysql -u skyhost1_admin -p skyhost1_shop < backup.sql

If the dump is compressed, pipe it through in one line instead of decompressing to disk first:

zcat backup.sql.gz | sed 's/utf8mb4_0900_ai_ci/utf8mb4_unicode_ci/g' | mysql -u skyhost1_admin -p skyhost1_shop

Option 3: Take a Cleaner Dump From the Source

If you control the original MySQL 8 server, the better long-term fix is exporting with a MariaDB-compatible collation from the start, rather than patching the dump afterward:

mysqldump --default-character-set=utf8mb4 \
  --skip-set-charset \
  -u root -p source_db > clean_backup.sql

This won't force MariaDB-safe collations on every table definition by itself (MySQL will still write whatever collation each table actually uses), but combined with a quick sed pass as above, it gives you a dump that's much closer to portable from the start. If you're setting up a recurring migration or sync between a MySQL 8 source and a MariaDB/cPanel destination, build the sed substitution into the export script permanently rather than fixing it by hand every time.

What If the Import Already Half-Ran?

If you already hit the error mid-import, don't just re-run the fixed file on top — you'll get duplicate table errors for everything that succeeded the first time. Drop the target database (or every table in it) and start clean with the corrected dump:

mysql -u skyhost1_admin -p -e "DROP DATABASE skyhost1_shop; CREATE DATABASE skyhost1_shop CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;"
mysql -u skyhost1_admin -p skyhost1_shop < backup_fixed.sql

Pre-creating the database with an explicit collation like this also helps if the dump's own CREATE DATABASE statement is what's carrying the bad collation, since your target database's default takes over for any table that doesn't override it.

Prevention

  • Before importing any dump from an unfamiliar source, grep it for the collation name first: grep -o "utf8mb4_[a-z0-9_]*" backup.sql | sort -u tells you in one line whether you're about to hit this.
  • Ask whoever hands you a database export which engine and version produced it. "MySQL" and "MariaDB" get used interchangeably by people who don't know the difference matters.
  • If you're building an automated migration pipeline, put the collation sed substitution in the script itself so nobody has to remember it under pressure during a live cutover.
  • Test-import into a scratch database first for anything that came from an unknown source, rather than importing straight over a production database.

Frequently Asked Questions

Does this mean cPanel doesn't support MySQL 8?

Most cPanel servers run MariaDB, which is a separate fork with its own collation set, not MySQL 8 itself. Some hosts do offer actual MySQL as an option in WHM, but if you didn't specifically request that, you're almost certainly on MariaDB — which is why MySQL 8-specific collations aren't recognized.

Will replacing the collation change how my data looks (accents, sorting, emoji)?

utf8mb4_unicode_ci and utf8mb4_0900_ai_ci are both Unicode-aware, case-insensitive collations built on utf8mb4, so stored data (including emoji and accented characters) displays identically. The only practical difference is sort order for certain characters in ORDER BY queries, which is rarely noticeable outside of very specific multilingual sorting requirements.

Can I just tell MariaDB to accept the unknown collation instead of editing the file?

Not from a standard cPanel account — that would require server-level MariaDB configuration changes that aren't exposed in cPanel, and newer MariaDB versions only alias a subset of MySQL 8 collations, not all of them. Editing the dump is faster and works regardless of what MariaDB version the server is running.

Why did a colleague's identical database import fine somewhere else?

They were probably importing into an actual MySQL 8 server, or a newer MariaDB build that happens to alias that particular collation. It's server-version-dependent, which is exactly why the same dump can work on one host and fail on another.

Is there a way to check what collation my cPanel database is actually using?

Run SHOW TABLE STATUS FROM skyhost1_shop; in phpMyAdmin's SQL tab or over SSH, and check the Collation column for each table. You can also see the server's own default with SHOW VARIABLES LIKE 'collation_server';.