WordPressで画像を追加しようとすると、
「ディスクへのファイルの書き込みに失敗しました」と表示されて困っていませんか?
記事の編集やログインはできるのに、画像だけアップロードできない。
検索で見つけた方法を試しても直らないと、どこを確認すべきか迷ってしまいます。
このエラーでは、最初から wp-content/uploads/ の権限を変更するのはおすすめしません。
多くの場合、確認すべき場所は画像の最終保存先より手前にあります。
ITエンジニアとして20年以上WordPressに携わってきたよこやま良平です。わたしが実際の復旧現場で確認した事例をもとに、初心者でも原因を切り分けられる順番で解説します。
- 「ディスクへのファイルの書き込みに失敗しました」の意味
- uploadsの権限を変えても直らない理由
- 一時フォルダとクォータを安全に確認する方法
- 原因別の対処法と、実際に復旧した事例
- 同じエラーを繰り返さないための予防策
結論から言うと、WordPress標準のメディア追加でこの文言が出た場合、
PHPがアップロード中の一時ファイルをディスクへ書けなかった可能性が高いです。
原因は空き容量だけとは限りません。
アカウントごとの割り当て上限、権限や所有者、inode不足なども含めて順番に確認しましょう。
WordPress画像アップロード失敗で書き込みエラーが出る意味
このエラーは、WordPressが画像を uploads へ移す前の段階で、
PHPのファイル受信処理が失敗したことを示します。
ブラウザから送った画像は、いきなりメディアライブラリへ入るわけではありません。
まずPHPが一時ファイルとして受け取り、その後にWordPressが最終保存先へ移します。

画像は4つの段階を通って保存されます
- ブラウザが画像をサーバーへ送る
- PHPが一時ファイルとしてディスクへ書き込む
- WordPressが
wp-content/uploads/へ移動する - 縮小画像を生成し、メディア情報を登録する
「ディスクへのファイルの書き込みに失敗しました」は、
2番の段階でPHPから返されたエラー番号7をWordPressが日本語で表示したものです。
PHPのエラー番号で失敗した段階を見分けられます
WordPress標準のアップロード処理は、PHPのエラー番号に応じて文言を変えます。
よく見る番号を整理すると次のとおりです。
| PHPの番号 | WordPressの主な表示 | 確認する内容 |
|---|---|---|
| 1 | php.iniのupload_max_filesizeを超過 | PHP側のサイズ上限 |
| 2 | HTMLフォームのMAX_FILE_SIZEを超過 | フォーム側のサイズ上限 |
| 6 | 一時フォルダーがありません | 一時ファイルを作る場所 |
| 7 | ディスクへのファイルの書き込みに失敗しました | 一時ファイルへの書き込み |
一方、PHPの受信に成功したあとで uploads への移動に失敗すると、
WordPressは「アップロードしたファイルを○○に移動できませんでした」という別の文言を返します。
WordPress画像アップロード失敗の主な原因
書き込みエラーの原因は、空き容量不足だけではありません。
とくに共有サーバーでは、全体の空きと利用者ごとの上限を分けて考える必要があります。
ディスク容量またはinodeを使い切っている
サーバーのファイルシステムが満杯になると、新しい一時ファイルへデータを書けません。
取り忘れたバックアップや、増え続けたログが原因になることがあります。
容量に空きがあっても、作成できるファイル数の上限である「inode」を使い切ると、No space left on device が出る環境もあります。
アカウントのクォータを超えている
共有サーバーでは、利用者ごとや領域ごとに書き込み上限が設けられることがあります。
この割り当て上限を「クォータ」と呼びます。
サーバー全体には空きがあっても、自分のアカウントや一時領域の枠が満杯なら書き込めません。
そのため、管理画面に「空きあり」と表示されるだけでは判断できない場合があります。

権限・所有者・一時パス・I/Oに問題がある
一時フォルダへアクセスするPHPの実行ユーザーに書き込み権限がない場合も失敗します。
数字のパーミッションだけでなく、フォルダの所有者とグループが重要です。
ほかにも、存在しない一時パス、inodeクォータ、読み取り専用になったファイルシステム、
ストレージのI/O障害やサーバー側のセキュリティ制約などが候補になります。
- ディスクまたはinodeの空き不足
- アカウント・領域ごとの容量またはinodeクォータ超過
- 一時フォルダの権限・所有者の不一致
- 一時フォルダ設定やサーバー側ストレージの異常
WordPress画像アップロード失敗を安全に診断する手順
原因を早く見つけるには、パーミッションを変更する前に、
一時フォルダへ実際に書き込めるかを確認するのが近道です。
初心者はサーバー管理画面から順番に確認する
- サーバー管理画面でディスク使用量とファイル数を確認する
- バックアップやログが急に増えていないか確認する
- WordPress本体・プラグインの更新も失敗していないか確認する
- 小さな画像でも同じ文言になるか確認する
- 判断できなければサーバー会社へエラー文を送る
サーバー会社がわからない場合は、次の調査ツールも利用できます。
契約先を確認してから、サポートへ相談すると話が早く進みます。
診断スクリプトで実際の一時フォルダを試し書きする
FTPでファイルを設置できる場合は、次のコードで切り分けできます。upload_tmp_dir が設定されている環境では、その実パスも検査するようにしています。
CHANGE_THIS_TO_RANDOM_20_CHARSを推測されにくい文字列へ変更する- 確認中だけ設置し、終わったら必ず削除する
- 表示結果を掲示板やSNSへそのまま貼らない
<?php
header('Content-Type: text/plain; charset=UTF-8');
$key = 'CHANGE_THIS_TO_RANDOM_20_CHARS';
if (!isset($_GET['key']) || !hash_equals($key, (string) $_GET['key'])) {
http_response_code(403);
exit('403 Forbidden');
}
function last_error_message() {
$error = error_get_last();
return $error['message'] ?? '詳細なエラーなし';
}
function probe($label, $dir) {
echo "== {$label} ==\n";
echo "パス: " . var_export($dir, true) . "\n";
if ($dir === '' || !is_dir($dir)) {
echo "結果: フォルダが存在しません\n\n";
return;
}
echo "is_writable: " . (is_writable($dir) ? 'YES' : 'NO') . "\n";
$free = @disk_free_space($dir);
echo "空き容量: " . ($free === false ? '取得できません' : $free . ' bytes') . "\n";
$path = rtrim($dir, DIRECTORY_SEPARATOR)
. DIRECTORY_SEPARATOR
. 'qr_probe_' . bin2hex(random_bytes(6)) . '.tmp';
error_clear_last();
$fp = @fopen($path, 'xb');
if (!$fp) {
echo "作成失敗: " . last_error_message() . "\n\n";
return;
}
error_clear_last();
$written = @fwrite($fp, str_repeat('x', 1048576));
$write_error = error_get_last();
@fclose($fp);
@unlink($path);
if ($written === 1048576) {
echo "1MB書込: OK\n\n";
} else {
$detail = $write_error['message'] ?? '詳細なエラーなし';
echo "1MB書込: NG / 書込バイト数="
. var_export($written, true) . " / {$detail}\n\n";
}
}
echo "読み込み中のphp.ini: "
. var_export(php_ini_loaded_file(), true) . "\n";
echo "追加ini: "
. var_export(php_ini_scanned_files(), true) . "\n";
$upload_tmp = trim((string) ini_get('upload_tmp_dir'));
echo "upload_tmp_dir: " . var_export($upload_tmp, true) . "\n";
echo "sys_temp_dir: "
. var_export(ini_get('sys_temp_dir'), true) . "\n\n";
if ($upload_tmp !== '') {
probe('upload_tmp_dir', $upload_tmp);
} else {
echo "upload_tmp_dirは未指定です。システム既定を確認します。\n\n";
}
$system_tmp = sys_get_temp_dir();
if ($system_tmp !== $upload_tmp) {
probe('sys_get_temp_dir', $system_tmp);
}ファイル名を check-upload-temp.php としてWordPressの公開フォルダへ置き、
次のように自分で設定したキーを付けて開きます。
https://あなたのドメイン/check-upload-temp.php?key=設定したランダム文字列作成失敗または1MB書込NGのメッセージを読む
見る場所は「作成失敗」または「1MB書込: NG」の直後です。
空き容量の数字だけでなく、実際の試し書きの結果を優先します。

| 表示例 | 主な確認先 |
|---|---|
No space left on device | ディスク容量、inode、ログ、バックアップ |
Disk quota exceededDisc quota exceeded | 容量クォータ、inodeクォータ、アカウントの割り当て |
Permission denied | 実行ユーザー、所有者、グループ、権限、セキュリティ制約 |
| フォルダが存在しません | 読み込まれた設定と実際のパス |
0バイトのファイルは作れても、データを書いた時に失敗する場合は、
容量やクォータ超過の強い手がかりになります。ただし、それだけで原因を断定はできません。
check-upload-temp.phpをサーバーから削除する- 検索エンジンや第三者から開けないことを確認する
- 共有した結果にパスやアカウント名が含まれていないか確認する
WordPress画像アップロード失敗の原因別対処法と復旧事例
対処法は、診断で確認できた原因に合わせて選びます。
初心者の方は、削除対象を判断できないままSSHコマンドを実行しないでください。
容量・inode・クォータ超過は不要物を特定して空ける
管理画面で古いバックアップや肥大化したログを確認し、
必要なものを別の安全な場所へ保存してから整理します。
SSHが使える方は、次の読み取り専用コマンドで状況を確認できます。アカウント名 は実際のサーバーアカウントへ置き換えてください。
# アカウントの割り当て状況
quota -h -v
# ファイルシステムの容量とinode
df -h
df -i
# 一時領域にある自分のファイルを大きい順に確認
find /tmp /var/tmp -user アカウント名 -type f -ls 2>/dev/null \
| sort -k7 -rn | head -40
# 自分のファイル数
find /tmp /var/tmp -user アカウント名 -type f 2>/dev/null \
| wc -l- ファイル名、所有者、日時、容量を一覧で確認する
- バックアップ処理や別システムが現在使用中でないか確認する
- 日数や
sess_*という名前だけで不要と判断しない - 判断できなければ一覧をサーバー会社へ送り、削除を依頼する
PHPセッションの保持期間は、サーバー設定や利用中のシステムによって異なります。
「1日以上前なら安全」のような一律の削除は、ログアウトや処理中断を招くため避けましょう。
一時フォルダの場所を変更する時は影響範囲を確認する
サーバー会社が許可している場合は、HTTPアップロード用の一時フォルダを、
余裕のある専用領域へ変更する方法があります。
upload_tmp_dir = /home/アカウント名/tmp/php-upload指定先は先に作成し、PHPの実行ユーザーが書ける所有者・グループ・権限にします。
適切な設定はサーバー構成で変わるため、ホスティング会社の案内を優先してください。
upload_tmp_dir と sys_temp_dir は、PHPの変更モードでは INI_SYSTEM です。.user.ini や実行中の ini_set() では変更できません。
一般的には、サーバー管理画面のphp.ini設定や管理者側のサーバー設定から変更します。sys_temp_dir はPHP全体へ影響するため、画像アップロードだけが目的なら安易に同時変更しない方が安全です。
実例では別システムのバックアップ残骸が原因だった
今回の復旧事例では、WordPressの設定や uploads の権限は正常でした。
画像アップロードだけでなく、その少し前からWordPress本体の更新も失敗していました。
- 画像だけが「ディスクへのファイルの書き込みに失敗しました」で止まる
- 記事の投稿とログインは正常
- uploadsのパーミッションは正常
- ファイルシステムには18GB以上の空きが表示される
試し書きでは、空き容量が約18GBと表示された一方で、Disc quota exceeded が返りました。
空き容量 : 18125922304
1MB書込 : NG
Disc quota exceeded一時領域を確認すると、前日に失敗した別システムのバックアップ処理が、
書き出し途中のファイルを大量に残していました。
- 同じ時刻に生成されたバックアップXML・画像・音声など
- 合計23,741ファイル
- 使用量は約990MB
- 一時領域のクォータは1GB
生成元・時刻・所有者・処理の停止を確認したうえで、対象の残骸だけを整理しました。
その結果、一時領域の使用量は990MBから8KBまで減りました。
この時点でWordPress側の設定やuploadsの権限を変えなくても、
画像アップロードは正常に復旧しました。
WordPress画像アップロード失敗を繰り返さない予防策
再発を防ぐには、バックアップ・一時領域・ログを定期的に点検します。
ホームディレクトリに余裕があっても、一時領域の枠が小さい構成は珍しくありません。
大きなバックアップの前後にクォータを確認する
エクスポートやバックアップを始める前に、使用量とファイル数を確認します。
処理に失敗した時は、完成ファイルだけでなく一時ファイルが残っていないかも確認してください。
ログを有効にする時は保存先とローテーションも決める
PHPの関連警告がエラーログへ残る場合があります。
ログを使う時は、公開フォルダの外を保存先にし、定期的にローテーションしてください。
log_errors = On
error_log = /home/アカウント名/log/php/php.loglog_errors を有効にしても、OSの詳細な書き込み理由が必ず残るとは限りません。
根本原因は実際の試し書き、クォータ、サーバー会社の調査も合わせて判断します。
一時フォルダとWordPress全体を定期点検する
サーバー会社が対応しているなら、WordPress用のアップロード一時領域を分ける方法もあります。
ただし、設定変更後は必ず所有者・書き込み・実アップロードを確認してください。
容量、バックアップ、更新、ログをまとめて確認することで、
画像アップロードが止まる前の小さな前兆に気づきやすくなります。
WordPress画像アップロード失敗のよくある質問
最後に、同じエラーでよく聞かれる質問へまとめて回答します。

WordPress画像アップロード失敗の解決方法まとめ
「ディスクへのファイルの書き込みに失敗しました」は、
標準のメディア追加では、uploadsへ移動する前のPHP一時ファイル書き込みで発生するエラーです。
- 最初からuploadsを777にしない
- ディスク容量・inode・クォータを分けて確認する
- 実際のupload_tmp_dirとシステム一時フォルダを試し書きする
- 削除前にファイルの所有者・日時・生成元を特定する
- 判断できない時はエラー文と診断結果をサーバー会社へ伝える
今回の事例では、別システムの失敗したバックアップが一時領域のクォータを使い切っていました。
原因を確認して対象だけを整理したことで、WordPressの設定を変えずに復旧しています。
推測で設定を変える前に、まず「どの場所へ、なぜ書けないのか」を確認しましょう。
それが安全で早い解決につながります。
WordPressの画像アップロードエラーが自分で解決できない時は

画像が1枚も追加できない、WordPressの更新まで止まる、原因を判断できない場合は、
クイックレスキューへご相談ください。
- 「ディスクへのファイルの書き込みに失敗しました」が直らない
- サーバーの容量は空いているのに画像を追加できない
- SSHやphp.iniの操作に不安がある
- 削除してよいファイルを判断できない
- WordPressの更新も失敗している
- 万一復旧できない場合やマルウェア駆除できない場合は全額返金保証で安心
- 90日間再感染保証・動作保証で安心
- 初期費用・調査費用0円で安心





