Chaque fichier envoyé au site (image, extension, thème, import) est d’abord écrit par PHP dans un dossier temporaire du serveur, puis déplacé à sa place. Ce message signale que PHP n’a pas pu écrire ce fichier temporaire, ou qu’il a disparu avant la fin de l’envoi. Le site continue de fonctionner, mais les envois de fichiers échouent.
Pourquoi cette erreur apparaît
- Le dossier temporaire du serveur est plein. Il est souvent séparé de votre espace d’hébergement et bien plus petit : il peut saturer alors qu’il vous reste de la place.
- Le quota de l’hébergement est atteint, en espace disque ou en nombre de fichiers, très souvent à cause de sauvegardes laissées sur le serveur.
- Le dossier temporaire existe mais PHP n’a plus le droit d’y écrire, après une migration, un changement de version de PHP ou une modification des droits.
- Un antivirus du serveur ou un nettoyage automatique supprime le fichier pendant l’envoi, avant que WordPress ait pu le récupérer.
Comment corriger le problème
Faire un essai avec un tout petit fichier
Envoyez une image très légère, de quelques dizaines de Ko, dans Médias > Ajouter. Si elle passe et que vos fichiers habituels échouent, le dossier temporaire manque de place pour les gros envois. Si même ce petit fichier échoue, le problème vient d’un dossier plein ou interdit en écriture, et la suite de cette fiche s’applique.
Libérer de l’espace sur l’hébergement
Dans votre espace client, regardez l’espace disque utilisé et, s’il est affiché, le nombre de fichiers (inodes). Les gros consommateurs habituels sont les sauvegardes stockées sur le serveur (wp-content/updraft, wp-content/ai1wm-backups, archives .zip ou .wpress à la racine), les dossiers de cache et les fichiers error_log. Téléchargez une copie de ces sauvegardes sur votre ordinateur avant de les supprimer du serveur.
Identifier le dossier temporaire et son état
Créez à la racine du site un fichier nommé test-tmp.php contenant le code ci-dessous, ouvrez-le dans le navigateur (https://votre-site.fr/test-tmp.php), notez le résultat, puis supprimez le fichier tout de suite. Il indique le dossier utilisé par PHP, s’il accepte l’écriture et la place qui y reste. Un dossier « NON accessible en écriture » ou presque plein est à signaler tel quel à l’hébergeur : sur un mutualisé, ce dossier ne se règle pas depuis WordPress.
<?php
$dir = ini_get( 'upload_tmp_dir' ) ?: sys_get_temp_dir();
echo $dir . ' : ' . ( is_writable( $dir ) ? 'accessible en écriture' : 'NON accessible en écriture' );
$libre = @disk_free_space( $dir );
echo ' / espace libre : ' . ( false === $libre ? 'inconnu' : round( $libre / 1048576 ) . ' Mo' );Vérifier l’antivirus de l’hébergement
Sur les hébergements équipés d’un antivirus en temps réel (Imunify360, ClamAV, Maldet), un fichier jugé suspect est supprimé ou mis en quarantaine pendant son envoi, ce qui produit exactement ce message. Regardez le journal de l’antivirus dans l’espace client, ou demandez à l’hébergeur s’il a bloqué un fichier à l’heure de votre essai. Une extension en .zip ou un fichier contenant du code est le cas le plus fréquent.
Corriger le dossier sur un serveur dédié ou un VPS
Vérifiez la place et le nombre de fichiers disponibles dans /tmp avec df -h /tmp et df -i /tmp : un /tmp monté en mémoire (tmpfs) est souvent limité à quelques centaines de Mo. Le plus fiable est de donner à PHP-FPM un dossier temporaire dédié, en dehors du dossier public, appartenant à l’utilisateur qui exécute PHP, puis de redémarrer PHP-FPM. Si une restriction open_basedir est active, elle doit inclure ce dossier. Derrière Nginx, le corps de la requête transite aussi par client_body_temp_path, qui doit disposer de la même marge.
; dans le pool PHP-FPM du site (exemple : /etc/php/8.3/fpm/pool.d/site.conf)
php_admin_value[upload_tmp_dir] = /var/www/site/tmp
php_admin_value[sys_temp_dir] = /var/www/site/tmpFaites une sauvegarde complète du site, fichiers et base de données, avant toute manipulation.
Un autre message d'erreur ? Collez-le dans le décodeur : il le reconnaît et vous oriente vers la bonne fiche.
Ouvrir le décodeur