WordPressで「一時フォルダーが見つかりません」と出た時の直し方

WordPressで画像やテーマをアップロードした時に、「一時フォルダーが見つかりません」と表示されたら、ファイルを何度も選び直すより、PHPが一時保存先を使えるか確認するのが先です。
このエラーは、アップロード容量の上限とは別の問題として切り分ける必要があります。

結論は、現在の状態を残したうえで、PHPの一時ディレクトリ、空き容量、権限、サーバー設定の順に確認することです。
原因を特定せずにパーミッションを広げたり、設定ファイルを何枚も追加したりすると、復旧後の安全性まで損ないます。

よこやま良平

20年以上ITエンジニアとしてWordPressの制作・保守・復旧に携わっている、よこやま良平です。
この症状はWordPressだけを見ても直らないことが多いため、サーバー側を含めた安全な確認順を解説します。

管理画面に入れるから軽い不具合だとは限りません。
PHPは受信したファイルを一時領域へ置いてからWordPressへ渡すため、その入口が使えないと、メディアだけでなくテーマやプラグインの追加も止まります。

この記事では、エラーの意味、原因の見分け方、設定変更の優先順位、再発防止までを一つの流れにまとめます。
サーバー会社へ依頼する場合も、何を確認してもらうべきかが分かる構成です。

【無料プレゼント】
WordPress緊急チェック50

「自分のサイトは今、安全なのか？」
自信を持って答えられますか？

こんなお悩みはありませんか？

• ある朝、サイトを開いたら真っ白画面になっていた
• 管理画面にログインできなくなって手が止まった
• 身に覚えのない記事やページが勝手に増えていた
• プラグインを更新したらサイト全体が崩れてしまった
• 以前バックアップを取ったか自分でも覚えていない

累計1,000件以上のWordPressトラブル対応の経験から、「壊れる前に備える」ためのチェックリストを1冊にまとめました。
ログイン・本体・バックアップ・サーバー・運用の5分野を、50項目で「危険度・確認方法・対処法」まで解説しています。

セキュリティプラグイン・WordPressの教科書も含めた3大特典を、
今なら無料で受け取れます。

今すぐ無料ダウンロードする →

※登録後すぐにメールで特典をお届けします

WordPressの「一時フォルダーが見つかりません」が示す状態

このエラーが出た時の結論は、WordPressへ届く前の一時保存処理を優先して調べることです。
画像の形式やメディアライブラリの設定だけを変更しても、PHPが受信場所を確保できなければアップロードは完了しません。

PHPは受信ファイルを一度だけ一時領域へ置く

ブラウザから送信されたファイルは、いきなり「uploads」フォルダーへ保存されるわけではありません。
まずPHPがサーバーの一時ディレクトリへ受け取り、その後にWordPressがファイル形式や権限を確認して、年月別の保存先へ移動します。

「一時フォルダーが見つかりません」は、この最初の受け取り段階でPHPが利用可能な場所を確保できなかった時に出る代表的なメッセージです。
PHPのアップロードエラーコードでは、一般に「UPLOAD_ERR_NO_TMP_DIR」に対応する状態として扱われます。

アップロード上限超過とは確認場所が違う

容量上限を超えた場合は、upload_max_filesize、post_max_size、Webサーバー側の制限などが中心です。
一方、一時フォルダーのエラーは、保存先の未設定、消失、書き込み不可、容量不足など、ファイルを置く場所そのものを疑います。

同じ「画像をアップロードできない」という症状でも、表示メッセージごとに入口を分けることが重要です。
上限値を大きくしても、一時領域が使えない問題は解決しません。

WordPressでメディアのアップロード上限を変更する方法｜php.iniとサーバー設定

最初に残すべき情報は四つある

変更前に、エラー全文、発生時刻、対象ファイル名と容量、直前に行った操作を記録してください。
同じ時間帯のPHPエラーログやサーバーログを探す時に、この四つが手掛かりになります。

業務サイトでは、再現テストを繰り返す前にバックアップ状況も確認します。
一時領域の不具合がディスク不足から起きている場合、追加のログやバックアップ生成が残容量をさらに圧迫することがあるためです。

WordPressで一時フォルダーを失う主な原因

主な原因は、PHP設定、実ディレクトリ、空き容量、実行ユーザーの四つです。
一つずつ確認すれば、WordPress本体やデータベースを触らなくても原因範囲をかなり絞れます。

upload_tmp_dirの指定先が存在しない

PHPの「upload_tmp_dir」に独自パスが設定されている環境では、その場所がサーバー移行や構成変更後に存在しないことがあります。
古い絶対パスがphp.iniや.user.iniに残ると、画面表示は正常でもアップロード時だけ失敗する場合があります。

ただし、upload_tmp_dirが空欄なら必ず異常という意味ではありません。
PHPはOSの既定一時領域を利用できるため、空欄だけを根拠に値を追加せず、実際に使われるパスと書き込み可否を確認します。

一時ディレクトリが消失または書き込み不可になった

指定先が存在していても、PHPを動かすユーザーに書き込み権限がなければ受信ファイルを作れません。
サーバー移行、PHP実行方式の変更、所有者の変更、復元作業のあとに、ディレクトリと実行ユーザーの組み合わせがずれることがあります。

共有サーバーでは、見えているFTPユーザーとWebサーバーやPHPの実行ユーザーが同じとは限りません。
数字だけで権限を決めず、所有者・グループ・実行方式をサーバー会社の仕様と照合する必要があります。

ディスク容量またはinodeが不足している

ディスクの空き容量がなくなると、一時ファイルを作成できず、同様のエラーにつながることがあります。
容量表示に余裕があっても、小さなファイルが極端に増えてinode上限へ達すると、新規ファイルを作れません。

確認対象はWordPressのuploadsだけではありません。
バックアップ、キャッシュ、アクセスログ、エラーログ、メールボックス、サーバー側の一時領域まで含めて、使用量の増加源を調べます。

PHPバージョンや実行環境ごとに設定が分かれている

管理画面で変更したphp.iniが、対象ドメインや現在のPHPバージョンへ反映されていない例もあります。
CLI版PHP、Web版PHP、サブドメイン、ステージング環境で読み込む設定ファイルが異なると、確認した値と実際の動作が一致しません。

PHPバージョン変更の直後に発生した場合は、変更前へ戻す判断も含めて検証します。
ただし本番で何度も切り替えず、設定値、拡張機能、実行方式を記録してから一回ずつ確認してください。

WordPressのPHPバージョン変更で失敗しない方法｜互換性確認と切り戻し手順

WordPressの一時フォルダーを安全に診断する手順

診断は、影響範囲の確認から始め、WordPress、PHP、OSまたは契約環境の順に下へ降りるのが安全です。
最初から設定ファイルを書き換えず、読み取りだけで分かる情報を集めます。

手順1：小さい画像と別のアップロード機能を比較する

まず、個人情報を含まない小さなJPEGまたはPNGを一枚だけ試します。
同じファイルを連続送信せず、メディア追加、テーマ追加、プラグイン追加のうち、必要な範囲だけを比較してください。

小さい画像でも同じ文言なら、ファイル容量より一時領域を優先します。
画像だけ失敗してテーマは通る場合は、画像処理ライブラリ、ファイル形式、セキュリティ制限など別経路も残るため、一時フォルダーだけに決めつけません。

手順2：サイトヘルスとサーバー管理画面で現在値を見る

WordPressの「ツール」から「サイトヘルス」「情報」を開き、サーバー、PHPバージョン、アップロード上限、ディレクトリ情報を記録します。
次にサーバー管理画面で、対象ドメインへ適用中のPHPバージョンと設定ファイルの場所を確認します。

画面に表示された値は、エラー発生時のWeb実行環境に近い情報として役立ちます。
ただし、一時ディレクトリの実在や所有者までWordPressから安全に判定できない環境もあるため、見えない項目を推測で補わないことが重要です。

WordPressのPHPメモリ不足を確認する方法｜500エラーと管理画面停止の対処

手順3：SSHが使える場合だけ読み取りコマンドで確認する

SSHを利用でき、対象サイトと同じPHP設定を参照することを確認できる場合は、次の読み取りコマンドで候補パスを確認できます。
表示されたサーバー内部のパスは公開せず、問い合わせや作業記録だけに使ってください。

php -r 'echo "upload_tmp_dir=".ini_get("upload_tmp_dir").PHP_EOL; echo "system_tmp=".sys_get_temp_dir().PHP_EOL; echo "writable=".(is_writable(sys_get_temp_dir())?"yes":"no").PHP_EOL;'

CLI版PHPとWeb版PHPは設定が異なることがあります。
コマンド結果が正常でもWordPressのエラーが続くなら、「CLIでは正常だから問題なし」と結論づけず、サーバー会社へWeb実行側のupload_tmp_dirと書き込み可否を確認してもらいます。

手順4：ログの時刻とPHPアップロードエラーを照合する

記録した発生時刻の前後で、PHPエラーログ、Webサーバーログ、ホスティングの障害情報を確認します。
「No such file or directory」「Permission denied」「No space left on device」などがあれば、パス、権限、容量のどこを優先すべきか判断できます。

ログに何も残らない場合もあります。
その時は、同一サーバー内の別サイトでも同じか、対象ドメインだけかを確認し、契約全体の障害とサイト固有設定を分けます。

手順5：一時フォルダー以外のエラーと区別する

413エラーはWebサーバー側の受信上限、HTTPエラーは通信・画像処理・WAFなど複数要因、書き込み失敗はuploads側の権限が中心になることがあります。
表示文言が変わったら、同じ原因と決めず、変更後のエラーを新しい証拠として扱います。

画像が保存されたのに表示だけ出ない場合は、URL、添付情報、キャッシュ、SSL混在などの確認が必要です。
一時フォルダーの復旧後も表示不具合が残る時は、アップロード処理と表示処理を分けて調べます。

WordPressで画像が表示されない原因とは？メディア設定とURLを確認する方法

WordPressの一時フォルダーを復旧する正しい順番

復旧は、バックアップと現状記録を済ませ、サーバーの標準設定へ戻す方向で進めるのが基本です。
独自パスを増やすより、対象PHPが確実に利用できる一時領域をサーバー仕様に合わせて整えます。

手順1：設定変更前にファイルとデータベースを保存する

管理画面に入れる状態でも、設定ファイルを触る前にWordPressファイルとデータベースを保存します。
ディスク不足が疑われる場合は、同じサーバー内へ巨大なバックアップを新規作成せず、サーバー会社のスナップショットや外部保存先を選びます。

保存後は、取得日時、保存先、復元方法をメモしてください。
バックアップファイルがあるだけでは不十分で、戻す対象と手順が分かって初めて設定変更の保険になります。

WordPressバックアップの完全解説｜UpdraftPlus / BackWPup / all-in-one-wp-migrationを図解

手順2：サーバー標準のPHP設定を優先する

レンタルサーバーにPHP設定画面がある場合は、対象ドメインとPHPバージョンを選び、標準値や推奨値を確認します。
古いupload_tmp_dirの独自指定が残っていれば、削除して既定へ戻すのか、正しい専用パスへ直すのかを仕様に沿って判断します。

php.ini、.user.ini、.htaccessへ同じ設定を重ねないでください。
どのファイルが優先されるか分からなくなり、復旧しても次回のPHP変更やサーバー移行で再発しやすくなります。

手順3：ディレクトリの存在・所有者・権限をそろえる

専用の一時ディレクトリを使う構成なら、実在すること、PHP実行ユーザーが書き込めること、外部公開されないことを確認します。
共用領域を自作する場合は、サーバー会社が許可する設置場所と権限値を必ず確認してください。

権限は大きい数字ほど良いわけではありません。
必要なユーザーだけが作成・削除できる状態にし、Webから一時ファイル一覧を見られない場所を選ぶことが、安全な復旧条件です。

手順4：共有サーバーでは確認事項をまとめて問い合わせる

サーバー内部の一時領域やPHP-FPMの実行ユーザーを利用者が確認できない場合は、無理に触らずサポートへ依頼します。
エラー文、発生時刻、対象ドメイン、PHPバージョン、直前の変更、試したファイル容量を一度に伝えると調査が進みます。

手順5：WP_TEMP_DIRは用途を区別して使う

wp-config.phpの「WP_TEMP_DIR」は、WordPressが更新やダウンロード処理で使う一時場所の候補を指定する定数です。
しかし、ブラウザからPHPが受信する段階で「一時フォルダーがない」と判定された場合、WP_TEMP_DIRだけでは直らないことがあります。

そのため、WordPress更新だけ失敗するのか、メディアアップロードでも同じエラーになるのかを先に分けます。
WP_TEMP_DIRを追加する場合も、サーバー仕様、実パス、権限、外部公開の有無を確認し、応急処置を恒久設定として放置しないでください。

手順6：小さいファイルから段階的に再テストする

修正後は、キャッシュを必要な範囲だけ消し、最初に小さな画像一枚をアップロードします。
成功したら、通常サイズの画像、プラグイン更新、テーマ更新など、実際に止まっていた処理を一つずつ確認します。

一度成功しただけで完了にせず、メディアライブラリへ正しく登録されたか、サムネイルが作成されたか、公開ページで表示できるかも確認します。
変更した設定値と確認結果を記録し、不要な検証ファイルや応急設定を片付けて復旧完了です。

WordPressの一時フォルダーエラーを再発させない対策

再発防止の結論は、設定変更の記録、容量監視、更新後テストを運用に入れることです。
一時領域は普段見えにくいため、問題がない時に基準値と確認方法を残しておくと復旧が早くなります。

PHP変更とサーバー移行では設定差分を残す

PHPバージョン、実行方式、設定ファイル、独自ディレクトリを変更したら、変更前後の値と理由を記録します。
サーバー移行では、ファイルとデータベースだけでなく、PHP設定、Cron、メール、WAF、ディレクトリ所有者も移行項目へ含めます。

ステージング環境で成功した設定が本番でも同じとは限りません。
ドメインごとのPHP適用範囲と、本番で読み込まれる設定ファイルを確認してから切り替えます。

容量とinodeを定期的に監視する

月次または更新作業前に、ディスク使用率、inode、バックアップ容量、ログ増加を確認します。
上限直前まで使う運用では、一時ファイルや更新展開に必要な余白を確保できません。

不要データを消す時も、用途と保存期限を確認してから実行します。
容量確保を急いで最新バックアップや障害ログを消すと、別のトラブルが起きた時に復旧材料を失います。

更新後の確認項目を固定する

WordPress本体、テーマ、プラグイン、PHPを変更した後は、表示確認だけで終わらせません。
ログイン、投稿保存、画像アップロード、メール送信、バックアップ、更新処理を短いチェックリストで確認します。

原因がPHPやサーバー側にある場合、WordPressの再インストールは第一選択ではありません。
障害層を正しく分け、必要な範囲だけ直すことが、データと運用を守る最短ルートです。

WordPressの一時フォルダーに関するよくある質問

WordPressの一時フォルダーエラーを安全に直す確認まとめ

「一時フォルダーが見つかりません」と出た時は、画像を繰り返し送信するのではなく、PHPが受信ファイルを置く場所を確認します。
アップロード上限、uploadsフォルダー、WP_TEMP_DIRは関連しますが、同じ役割ではありません。

自分で確認できる範囲を超えたら、設定を重ねる前にサーバー会社またはWordPress復旧の専門家へ相談してください。
現状と変更履歴を残しておけば、必要な修正だけを選びやすく、復旧後の再発防止にもつながります。

WordPressのアップロードエラーが自分で直せない時は

WordPress保守・不正アクセス対策・マルウェア駆除・WordPressクイックレスキュー365

ワードプレスのWordPressエラートラブル解決をしたいなら
クイックレスキューが解決します。

これらでお悩みなら最短30分ですぐに解決します！

いまなら期間限定で