Fix MariaDB “Error writing file .frm” During Import on Ubuntu

Getting Error writing file '.frm' while importing a MySQL database into MariaDB? The problem may not be disk space or permissions at all. In this case, the real issue was an unsupported MySQL 8 collation causing misleading MariaDB import errors on Ubuntu 24.04.

One of my clients recently asked me to rebuild a compromised WordPress VPS running an old Sentora/OVI stack. The new server was deployed on Ubuntu 24.04 with a clean MariaDB installation, and the WordPress files restored successfully.

The problem appeared during the database import.

MariaDB started throwing this error:

				
					ERROR 3 (HY000): Error writing file './database/table.frm'
(Errcode: 122 "Internal (unspecified) error in handler")

At first glance, it looked like a classic filesystem or disk issue.

That usually means:

But in this case, none of those were the real cause.

The actual issue turned out to be a MySQL 8 collation incompatibility causing MariaDB to fail with misleading low-level handler errors.

This happened during a WordPress VPS rebuild on Ubuntu 24.04 using MariaDB 10.11.

If you are migrating:

this is something worth checking before wasting hours debugging storage and permissions. This is a common issue under Web Server Errors and Linux Permissions.

Symptoms We Saw

The confusing part was that the server itself looked healthy.

Disk space was available.

Permissions looked correct.

MariaDB service was running normally.

That meant the next logical step was verifying whether MariaDB itself was actually able to write to its data directory correctly before assuming the database dump was corrupted.

Check Disk Space First

Even though this issue turned out to be unrelated to storage, disk space is still the first thing you should verify.

Check available disk space:

				
					df -h

Also check inode usage:

				
					df -i

In our case:

Since the storage layer looked healthy, the next logical step was verifying MariaDB permissions and service health.

Verify MariaDB Directory Permissions

Check the MariaDB data directory:

				
					ls -ld /var/lib/mysql

And verify the database directory ownership:

				
					ls -ld /var/lib/mysql/your_database

Expected ownership:

				
					mysql:mysql

In this case, permissions were already correct.

That ruled out another common cause of .frm write failures.

Since permissions were fine, the next thing to inspect was MariaDB logs and security restrictions.

Check MariaDB Logs and AppArmor

Check MariaDB logs:

				
					journalctl -u mariadb -n 50 --no-pager

Also check AppArmor status:

				
					aa-status

We specifically looked for:

Nothing unusual appeared.

At this point, the error became suspicious because MariaDB was failing to create tables even though:

That strongly suggested the SQL dump itself needed inspection.

Inspect the SQL Dump for MySQL 8 Collations

This turned out to be the real breakthrough.

We searched the SQL dump for collations:

				
					grep -oE 'CHARSET=[^ ]+|COLLATE=[^ ]+' database.sql | sort | uniq -c

That revealed this:

				
					COLLATE=utf8mb4_0900_ai_ci

This collation exists in MySQL 8, but MariaDB does not fully support it.

That is where the misleading behavior begins.

Instead of immediately reporting:

				
					Unknown collation: utf8mb4_0900_ai_ci

MariaDB sometimes throws much more confusing low-level handler errors like:

				
					Error writing file '.frm'
Internal (unspecified) error in handler

This is especially common during:

Since the dump clearly contained unsupported MySQL 8 collations, the next step was normalizing the SQL file before importing again.

Replace Unsupported Collations

Create a modified copy of the SQL dump:

				
					cp database.sql fixed.sql

Replace unsupported MySQL 8 collations:

				
					sed -i 's/utf8mb4_0900_ai_ci/utf8mb4_unicode_ci/g' fixed.sql

We also normalized older collations for consistency:

				
					sed -i 's/utf8mb4_unicode_520_ci/utf8mb4_unicode_ci/g' fixed.sql

Then verify the replacement:

				
					grep -R "0900_ai_ci" fixed.sql

The command should return nothing.

At this point, the import progressed further, but another issue appeared involving WordPress Action Scheduler tables.

Remove Problematic Action Scheduler Tables

The following tables caused additional import problems:

				
					wp_actionscheduler_actions
wp_actionscheduler_claims
wp_actionscheduler_groups
wp_actionscheduler_logs

These tables are commonly used by:

In many cases, these tables are safe to regenerate automatically after migration.

We removed them from the SQL dump and re-imported the database successfully afterward.

This is often the fastest and safest approach during WordPress recovery or VPS rebuild work.

Common Mistakes / Edge Cases

Assuming It Is Always Disk Space

This error looks exactly like a storage failure, but unsupported collations can trigger the same message.

Always inspect the SQL dump before rebuilding the filesystem.

Mixing MySQL 8 With MariaDB

This issue commonly happens when: old servers use MySQL 8, but the new VPS uses MariaDB 10.x or 11.x. The databases are compatible in many ways, but not completely identical.

Forgetting About Action Scheduler Tables

WooCommerce scheduler tables frequently become corrupted or problematic during migrations.

In many cases, removing them is easier than repairing them.

Importing Directly Without Inspecting The Dump

Always inspect: charset, collations, storage engines, and SQL modes before importing large production databases into a different database engine.

Need Help Fixing Your VPS?

If you’re stuck with server issues and need a reliable fix, I troubleshoot real VPS problems daily — from Nginx errors and SMTP failures to DNS and performance issues.

Instead of guessing, get a proven fix based on real experience.

Conclusion

In this case, MariaDB “Error writing file .frm” had nothing to do with:

The real problem was an unsupported MySQL 8 collation:

				
					utf8mb4_0900_ai_ci

Because MariaDB produced misleading low-level handler errors instead of a clean collation warning, the issue initially looked far more serious than it actually was.

If you are rebuilding a WordPress VPS or migrating from MySQL 8 to MariaDB, checking the SQL dump for unsupported collations should be one of the first troubleshooting steps.

Fix MariaDB “Error writing file .frm” During Import

(It May Not Be Disk Space)

Table of Contents