The server finds a .frm table-definition file whose header contains an unrecognized type identifier, causing MySQL to abort table access with error 1346.
MySQL Error 1346: ER_FRM_UNKNOWN_TYPE occurs when MySQL encounters a corrupted or version-mismatched .frm file. Recreate the table from a clean backup or dump to resolve the issue.
File '%s' has unknown type '%s' in its header
The error message “File '%s' has unknown type '%s' in its header” signals that MySQL cannot interpret the internal header of a .frm file. The header’s type byte tells the server which storage engine or format the table uses. When the value is missing, corrupted, or unfamiliar to the running server, MySQL raises error 1346 and aborts the operation.
The problem shows during any statement that opens the affected table: SELECT, INSERT, ALTER TABLE, CHECK TABLE, or even during server startup while loading data dictionary metadata. Replication workers will also stop if they reach the damaged table.
A table that triggers ER_FRM_UNKNOWN_TYPE is unreadable. Applications see immediate outages, and backups that rely on logical dumps will fail. Ignoring the corruption risks permanent data loss if the underlying disk continues to degrade.
Most cases stem from file corruption after abrupt power loss, disk failures, or incomplete file copies between servers running different MySQL versions. The header also becomes unrecognizable if the table was created with a third-party storage engine that is no longer installed.
First isolate the table by stopping writes or putting the schema in maintenance mode. Extract good data from backups or a replica that does not show the error. Recreate the table definition, then reload data. If no backup exists, attempt to salvage rows with a low-level tool such as mysqlfrm plus SELECT...INTO OUTFILE from the .ibd if InnoDB-file-per-table is enabled.
On-premise servers that crashed without innodb_flush_log_at_trx_commit=1 often corrupt MyISAM .frm headers; running REPAIR TABLE sometimes rewrites a valid header. Migration from MariaDB to MySQL 8 can break tables that used the Aria engine; reinstalling the corresponding plugin lets MySQL parse the header again.
Keep identical MySQL versions across all nodes, enable crash-safe settings, and verify backups daily. Use mysqldump or MySQL Shell dump to move tables instead of copying raw .frm files. Monitor the error log with Galaxy’s alerting to catch file issues early.
Error 1030 (HY000) ER_GET_ERRNO appears when the .frm file is intact but the underlying data file is missing. Error 126 (HY000) INDEX_CHKSUM_ERROR fires when index pages are corrupt. The troubleshooting flow is similar—verify backups, diagnose storage health, then rebuild the table.
Bad blocks on the storage device alter bytes in the .frm header, making MySQL read an invalid type value.
Copying .frm files from an older or MariaDB server introduces type codes that a newer MySQL release does not recognize.
If a table was created with a pluggable engine such as TokuDB, removing that plugin leaves the server unable to interpret the header.
Interrupted SCP or rsync operations leave the .frm truncated, wiping out the type byte in the header.
A crash while writing metadata can leave the header in an inconsistent, half-written state.
Signals OS-level failure reading table data files; often follows if the .ibd file is missing.
Occurs when MyISAM index files are corrupt; REPAIR TABLE may recover indexes.
Raised when the .frm file is missing entirely; recreate table or restore from backup.
Happens when a view references a table that was dropped or damaged.
If you still have a good backup, you can rename the corrupted .frm, copy a healthy .frm from backup, and run FLUSH TABLES; however, this risks version mismatches.
Yes. Although row data sits in .ibd files, the .frm header still describes the table and must be intact.
Upgrading rarely helps; the header is already unreadable. Upgrade only after restoring or rebuilding the table.
Galaxy centralizes vetted DDL in shared collections, discouraging raw file copies and catching corruptions through built-in linting and query history.
.avif)
.avif){kind=logo}
