Operations 8 min read

Why MySQL Errcode 28 Can Appear Even With Plenty of Disk Space

A MySQL fatal error claiming "Can't create/write to file ... (Errcode: 28)" turned out not to be a lack of disk space but exhausted inodes caused by millions of tiny maildrop files generated by cron‑driven Postfix notifications, and the article walks through the investigation and fix.

ITPUB
ITPUB
ITPUB
Why MySQL Errcode 28 Can Appear Even With Plenty of Disk Space

Problem Encountered

While working on a web page, the program threw a fatal MySQL error:

Fatal error: mysql error: [1: Can't create/write to file '/var/tmp/#sql_9469_0.MYI' (Errcode: 28)]

The error originates from the MySQL server and is marked as fatal. The message is unusually detailed compared with many other MySQL errors.

Initial Diagnosis

Searching online revealed that Errcode 28 usually means “No space left on device”. Running the standard Linux command confirms this:

$ perror 28
OS error code 28:  No space left on device

Checking disk usage with df showed that the system partitions were far from full (system disk 15 % used, data disk 25 % used), so the obvious cause—insufficient disk space—did not match the symptom.

Deeper Investigation: Inodes

Further research indicated that Errcode 28 can also arise when the filesystem runs out of inodes, i.e., the maximum number of files allowed, even if there is free space. A quoted comment from another article illustrates this:

I had same problem but disk space was okay (only 40% full). Problem were inodes, I had too many small files and my inodes were full. You can check inode status with df -i .

Running df -i on the server revealed that the /dev/vda1 partition had nearly 2 million files, approaching its inode limit.

Finding the Culprit Files

To locate the directory containing the massive number of files, the author used a brute‑force search: find DIR_NAME -type f | wc -l This command counts the total files under a given directory. The search highlighted a suspicious path: /var/spool/postfix/maildrop Inspecting this directory showed about 1.8 million files.

Understanding Postfix and Maildrop

Postfix is a mail server (originally created by Wietse Venema as an alternative to Sendmail). The maildrop directory is the mail queue where individual email messages are stored.

Examining one of the queued messages revealed it was addressed to the root user and contained output from the Cron daemon.

Root Cause: Cron‑Generated Emails

The server’s /etc/crontab file listed over 30 scheduled tasks, many of which run frequently. Each task was configured to send a status email to root. The accumulation of these automated emails filled the Postfix mail queue, exhausting inodes and triggering the MySQL Errcode 28.

The relevant snippet from /etc/crontab shows the mail configuration:

SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
HOME=/

Solution

To stop the flood of emails, change the MAILTO variable to an empty string, preventing cron from sending messages to root: MAILTO="" After clearing the maildrop directory, the inode count returned to normal and the MySQL error disappeared.

Conclusion

This case demonstrates how a seemingly unrelated MySQL fatal error can stem from system‑level issues such as inode exhaustion caused by excessive automated emails. Properly auditing cron jobs and mail server queues is essential for reliable server operation.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

mysqlcroninodespostfixErrcode28
ITPUB
Written by

ITPUB

Official ITPUB account sharing technical insights, community news, and exciting events.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.