メディアのアップロード時に「Failed to write file to disk.」（日本語環境では「ディスクへの書き込みに失敗しました」に相当する文言）と表示される場合、原因の多くはPHPがアップロードファイルを一時保存する段階で書き込めていないことです。この記事では、このエラーが出る仕組みを押さえたうえで、ディスク容量・一時ディレクトリ・権限の順に確認して直す手順を説明します。
このエラーが出る仕組み
ブラウザからファイルを送ると、PHPはまずそのファイルをサーバーの一時ディレクトリ（php.ini の upload_tmp_dir、未設定ならOSの標準の一時ディレクトリ。多くは /tmp）に書き込みます。WordPressはその一時ファイルを wp-content/uploads/年/月/ へ移動します。
「Failed to write file to disk」は、PHPのアップロードエラーコード UPLOAD_ERR_CANT_WRITE（値は7）に対応するメッセージです。WordPressはPHPから受け取ったエラーコードをそのまま文言に置き換えて表示しているだけなので、原因はWordPressの設定ではなく、最初の「一時ディレクトリに書き込む」段階にあると考えるのが近道です。
似たエラーと区別しておくと、調べる場所を間違えずに済みます。
- 「Missing a temporary folder」… 一時ディレクトリそのものが見つからない（
UPLOAD_ERR_NO_TMP_DIR） - 「The uploaded file could not be moved to …」… 一時保存には成功し、uploads への移動で失敗している
- 「Unable to create directory …」… uploads 配下に年月フォルダを作れない（権限の問題が多い）
後ろの2つは uploads 側の権限を疑いますが、「Failed to write file to disk」はまず一時ディレクトリ側を疑います。
原因1: ディスク容量やinodeが足りない（最も多い）
もっとも多いのは、サーバーの空き容量不足です。とくに /tmp が別パーティションやメモリ上（tmpfs）になっていて容量が小さい構成では、全体に余裕があっても一時ディレクトリだけが満杯になることがあります。
確認方法
SSHが使える場合は、容量とinode（ファイル数の上限）の両方を確認します。
df -h # 各パーティションの使用率
df -i # inode の使用率（小さなファイルが大量にあると先に尽きる）
df -h /tmp # 一時ディレクトリがあるパーティション
du -sh /path/to/wordpress/wp-content/* | sort -h | tail使用率が上限近くまで達しているパーティションがあれば、それが原因の可能性が高いです。共用レンタルサーバーではOSの容量ではなく契約ごとのディスク容量（クォータ）が上限になるため、サーバーの管理パネルで使用量を確認します。
直し方
容量を空けるときは、消す前に何のファイルかを確認し、必要ならバックアップを外部に退避してから削除します。WordPressでよく容量を食っているのは次の場所です。
- バックアッププラグインがサーバー内に残している古いバックアップファイル
wp-content/debug.logやPHPのエラーログが肥大化したもの- キャッシュプラグインのキャッシュディレクトリ
- 使っていないテーマ・プラグインや、移行作業で残った圧縮ファイル
ログが急に大きくなっている場合は、同じエラーが大量に出ていないかを先に確認してください。原因を直さずにログだけ消しても、すぐに再発します。恒常的に足りない場合は、プランの変更やディスクの拡張を検討します。
原因2: 一時ディレクトリに書き込めない
容量に余裕があるのにエラーが出る場合は、PHPの実行ユーザーが一時ディレクトリに書き込めていない可能性があります。
確認方法
PHPが実際に使っている一時ディレクトリを確認します。注意点として、コマンドラインのPHP（php -i や WP-CLI）と、Webサーバー経由で動くPHP（PHP-FPMやモジュール版）は別の php.ini を読んでいることがあります。Web経由で動くPHPの値を見るには、レンタルサーバーのPHP設定画面を確認するのが手軽です（サイトヘルスの「情報」タブでもPHPの動作方式やアップロード上限は確認できますが、表示項目はバージョンによって異なり、一時ディレクトリの場所までは分からないことがあります）。一時的に phpinfo() を出すファイルを置く方法もありますが、サーバー情報が外部から見えてしまうため、確認したらすぐに削除してください。
値が分かったら、そのディレクトリの権限と所有者を確認します。
ls -ld /tmp # 通常は drwxrwxrwt（1777）
ls -ld /path/to/upload_tmp # upload_tmp_dir を独自に指定している場合直し方
/tmp の権限が変更されていた場合は、サーバー管理者が標準の 1777 に戻します。独自の upload_tmp_dir を指定している場合は、そのディレクトリが存在し、PHPの実行ユーザーが書き込めることを確認します。
upload_tmp_dir はPHPの設定の中でもシステム側でしか変更できない項目で、.user.ini や ini_set() では変えられません。php.ini か、PHP-FPMのプール設定で指定します。
; php.ini の例（パスは環境に合わせて変更）
upload_tmp_dir = /var/lib/php/upload_tmp; PHP-FPM のプール設定（www.conf など）で指定する例
php_admin_value[upload_tmp_dir] = /var/lib/php/upload_tmp変更後はPHP-FPMやWebサーバーを再起動して反映させます。共用サーバーでこの項目を変えられない場合は、サーバー会社のサポートに「アップロード時にUPLOAD_ERR_CANT_WRITEが出る」と伝えると話が早いです。
なお、open_basedir で参照できるディレクトリを制限している環境では、一時ディレクトリが許可リストに含まれていないと書き込みに失敗することがあります。SELinuxなどのアクセス制御が有効なサーバーでも、ディレクトリの権限は正しいのに書き込めないことがあるため、サーバーのログもあわせて確認します。
原因3: uploads やWordPressの一時フォルダの問題
一時ディレクトリに問題がないのに改善しない場合は、念のためWordPress側も確認します。
wp-content/uploadsと年月フォルダの権限（一般的にはディレクトリ755、ファイル644。サーバーの推奨値があればそれに従う）- 所有者がPHPの実行ユーザーと合っているか。FTPやrootで作ったフォルダは所有者が違うことがある
- プラグインやテーマの更新時に同様のエラーが出る場合は、WordPressが一時ファイルに使うディレクトリ。
wp-config.phpのWP_TEMP_DIR定数で、書き込める場所を指定できる
// wp-config.php の例（「That's all, stop editing!」の行より上に書く）
define( 'WP_TEMP_DIR', __DIR__ . '/wp-content/temp/' );WP_TEMP_DIR に指定したディレクトリは事前に作成し、書き込み権限を与えておきます。Webから中身を見られないように、可能であれば公開ディレクトリの外を指定します。この定数はWordPressの処理（更新ファイルのダウンロードなど）が使う一時フォルダで、PHPのアップロード一時ディレクトリ（upload_tmp_dir）とは別物です。メディアのアップロードエラーには、原因1・2の対応が中心になります。
直ったかどうかの確認
設定を変えたら、小さな画像ファイルと、普段アップロードする程度の大きなファイルの両方で試します。小さいファイルだけ成功する場合は、一時ディレクトリの残り容量がぎりぎりのことがあります。大きなファイルでは「アップロードされたファイルが upload_max_filesize を超えています」のような別のエラーになることもありますが、こちらはサイズ上限の問題で、今回のエラーとは対処が異なります。
再発を防ぐには、ディスク使用率の監視と、バックアップの保存先をサーバー外（クラウドストレージなど）にする運用が効果的です。主要なバックアッププラグインの多くは外部保存に対応していますが、対応先は製品や版によって異なります（2026年10月現在）。
まとめ
- 「Failed to write file to disk」はPHPのアップロードエラー
UPLOAD_ERR_CANT_WRITEで、一時ディレクトリへの書き込み失敗を示す - 最初に
df -hとdf -iで容量とinodeを確認する。/tmpだけが満杯のケースもある - 容量に余裕があれば、Web経由のPHPが使う一時ディレクトリと、その権限・所有者を確認する
upload_tmp_dirは php.ini かPHP-FPMの設定でしか変えられない- 削除や設定変更の前にはバックアップを取り、ステージング環境で試せる場合はそちらで確認する