CHMOD WordPress : permissions sûres pour wp-content

Le besoin / Le problème serveur

Si vous avez déjà vu “Impossible de créer le répertoire wp-content/uploads” ou des images qui restent en “cassé” après un upload, vous êtes probablement face à un problème de permissions (droits) côté serveur.

Le piège, c’est que “mettre 777 partout” semble résoudre le symptôme… et ouvre votre site WordPress 6.9.4 à des écritures non autorisées. J’ai souvent croisé ce scénario après une migration FTP, une restauration, ou un changement de PHP-FPM où l’utilisateur système qui exécute PHP n’est plus le même.

À la fin, vous saurez :

• déterminer quel utilisateur doit écrire dans wp-content et wp-content/uploads ;
• appliquer une stratégie saine de chmod (droits) et chown (propriétaire) ;
• valider avec des commandes (SSH, WP-CLI) que WordPress peut écrire sans rendre le site “world-writable”.

Résumé rapide

• Objectif : répertoires en 755, fichiers en 644, et un propriétaire cohérent (souvent plus important que le chmod).
• Uploads : wp-content/uploads doit être écrivable par l’utilisateur qui exécute PHP (Apache module, PHP-FPM, ou user du pool).
• Évitez 777 et 666 (risque d’écriture par n’importe qui sur le serveur).
• Commandes clés : find ... -type d -exec chmod 755, find ... -type f -exec chmod 644, chown -R, wp media import ou un upload test.
• Mutualisé : vous n’avez souvent pas accès à chown ; dans ce cas, visez un 755/644 propre et corrigez via le support si le propriétaire est mauvais.

Avant de commencer (prérequis)

Vous allez modifier des droits système. Une erreur peut rendre le site inaccessible ou empêcher les mises à jour. Travaillez idéalement sur un staging (copie de test) avant production.

Accès nécessaires

• SSH (recommandé) : pour exécuter chmod, chown, find, lire les logs.
• WP-CLI (recommandé) : pour tester des opérations WordPress côté serveur.
• FTP/SFTP : utile si vous n’avez pas SSH (mais plus limité).
• Accès logs : /var/log/nginx/error.log, /var/log/apache2/error.log, logs PHP-FPM.

Sauvegarde obligatoire (avant toute commande)

Avant de toucher aux permissions, faites une sauvegarde des fichiers (au minimum wp-content). La commande ci-dessous crée une archive datée. Exécutez-la à la racine de WordPress.

# Sauvegarde minimale de wp-content (thèmes, plugins, uploads)
# À exécuter depuis la racine WordPress (là où se trouve wp-config.php)
tar -czf "backup-wp-content-$(date +%F-%H%M).tar.gz" wp-content

Versions serveur recommandées (avril 2026)

• WordPress : 6.9.4 (votre contexte)
• PHP : 8.1+ (8.2/8.3 souvent plus courant en prod)
• MySQL : 8.0+ ou MariaDB 10.6+ (selon hébergeur)
• Serveur web : Nginx ou Apache, souvent avec PHP-FPM

Si vous êtes sur une version PHP trop ancienne, vous pouvez avoir des comportements étranges (plugins qui échouent, erreurs fatales) qui masquent le vrai problème de permissions. Référence PHP : php.net – versions supportées.

Étape 1 : Identifier votre contexte (Apache/Nginx, PHP-FPM, propriétaire)

Avant de “chmod au hasard”, il faut comprendre qui écrit sur le disque. Sur un serveur Linux, un fichier a :

• un propriétaire (user),
• un groupe (group),
• des droits (lecture/écriture/exécution) pour : propriétaire, groupe, autres.

1) Trouver le répertoire WordPress et inspecter les droits actuels

Placez-vous dans le dossier où se trouve wp-config.php, puis listez wp-content et uploads.

# Aller à la racine WordPress (adaptez le chemin)
cd /var/www/site

# Vérifier propriétaire/groupe et permissions
ls -ld wp-content wp-content/uploads
ls -l wp-content | head

2) Identifier l’utilisateur qui exécute PHP

Le “bon” propriétaire dépend de votre stack :

• Apache + mod_php : souvent www-data (Debian/Ubuntu) ou apache (RHEL/CentOS).
• Nginx + PHP-FPM : PHP tourne via un pool (ex : www-data, nginx, ou un user dédié par site).
• Mutualisé : PHP tourne souvent sous votre utilisateur (ou via suPHP/suEXEC), et vous ne pouvez pas changer le propriétaire.

Option A : PHP-FPM (le cas le plus courant)

Essayez de trouver le pool actif et l’utilisateur configuré dans la conf. Les chemins varient selon distros, voici des commandes utiles.

# Lister les services PHP-FPM (selon version installée)
systemctl list-units --type=service | grep -E "php.*fpm"

# Exemple : afficher la conf du pool (adaptez 8.2/8.3/8.1)
grep -R "^s*users*=" -n /etc/php/*/fpm/pool.d 2>/dev/null
grep -R "^s*groups*=" -n /etc/php/*/fpm/pool.d 2>/dev/null

Option B : Apache

Sur Apache, cherchez l’utilisateur du service.

# Debian/Ubuntu
grep -R "^s*User|^s*Group" -n /etc/apache2/apache2.conf 2>/dev/null

# RHEL/CentOS (chemin courant)
grep -R "^s*User|^s*Group" -n /etc/httpd/conf/httpd.conf 2>/dev/null

3) Comprendre ce que WordPress doit pouvoir écrire

Sur un site standard, WordPress doit pouvoir écrire dans :

• wp-content/uploads (médias)
• wp-content/cache (si un plugin le crée)
• wp-content/upgrade (pendant une mise à jour)
• wp-content/plugins et wp-content/themes (si vous autorisez l’installation/mise à jour via l’admin)

La doc officielle sur la structure et les permissions est un bon repère : WordPress.org – Changing File Permissions.

Étape 2 : Appliquer les bons droits (chmod) et le bon propriétaire (chown)

Deux réglages différents :

• chmod : règle les droits (ex : 755, 644).
• chown : change le propriétaire/groupe (ex : www-data:www-data).

Dans mon expérience, 80% des “uploads impossibles” viennent d’un mauvais propriétaire après migration (ex : fichiers appartenant à root copiés via une archive), et pas d’un chmod “trop strict”.

Stratégie recommandée (générale)

• Répertoires : 755
• Fichiers : 644
• wp-config.php : souvent 640 ou 600 (à ajuster selon votre user/groupe)

Le principe : “lecture pour tous, écriture seulement pour le propriétaire”.

1) Fixer les permissions (chmod) proprement avec find

Ces commandes appliquent 755 aux dossiers et 644 aux fichiers, sans vous demander de tout sélectionner à la main. Exécutez-les depuis la racine WordPress.

# À exécuter depuis la racine WordPress
# Répertoires : 755
find . -type d -exec chmod 755 {} ;

# Fichiers : 644
find . -type f -exec chmod 644 {} ;

2) Fixer le propriétaire (chown) — seulement si vous avez les droits

Si vous êtes sur un VPS/dédié (ou conteneur) et que vous avez sudo, alignez le propriétaire sur l’utilisateur qui exécute PHP. Exemple Debian/Ubuntu typique : www-data.

# Exemple : donner la propriété à www-data (adaptez user:group)
# ATTENTION : vérifiez le bon user PHP avant.
sudo chown -R www-data:www-data /var/www/site

Si votre politique est d’avoir un utilisateur “déployeur” (ex : deploy) propriétaire des fichiers, et seulement le groupe web en écriture sur certains dossiers, vous pouvez faire une variante plus stricte (souvent meilleure en prod) :

• fichiers appartenant à deploy:www-data
• écriture autorisée au groupe www-data uniquement pour wp-content/uploads (et éventuellement cache, upgrade)

# Exemple "déployeur" + groupe web :
sudo chown -R deploy:www-data /var/www/site

# Donner l'écriture au groupe uniquement sur uploads
sudo chmod -R g+w /var/www/site/wp-content/uploads

# Option utile : setgid sur le dossier uploads
# Les nouveaux fichiers héritent du groupe www-data
sudo find /var/www/site/wp-content/uploads -type d -exec chmod 2775 {} ;

Le bit 2 de 2775 active le setgid sur les dossiers : pratique quand plusieurs outils écrivent (WP, déploiement, rsync) et que vous voulez un groupe cohérent.

3) Pourquoi éviter 777 (et quand on le voit)

777 = tout le monde peut écrire. Sur un serveur mutualisé, ou un serveur compromis, c’est une autoroute pour déposer des fichiers malveillants dans uploads (webshell, backdoor). Beaucoup d’infections WordPress commencent par un dossier world-writable.

La doc WordPress rappelle ce point (et les valeurs recommandées) : WordPress.org – permissions.

Étape 3 : Vérifier spécifiquement wp-content et uploads (et corriger sans casser)

wp-content et surtout wp-content/uploads sont les zones les plus sensibles. Ce sont aussi celles que les plugins et page builders (Divi 5, Elementor, Avada) sollicitent le plus : génération de CSS/JS, caches, images optimisées, fichiers temporaires.

1) Vérifier que WordPress pointe bien sur le bon répertoire d’uploads

WordPress stocke le chemin “logique” des uploads. En général, c’est wp-content/uploads, mais certains sites ont un chemin personnalisé (constant UPLOADS, ou filtre). Vérifiez dans la base via WP-CLI :

# Afficher l'option (souvent vide si valeur par défaut)
wp option get upload_path --skip-plugins --skip-themes
wp option get upload_url_path --skip-plugins --skip-themes

Si vous avez une constante define('UPLOADS', ...) dans wp-config.php, le chemin réel peut être différent. Ne corrigez pas “le mauvais dossier”.

2) Test d’écriture réel dans uploads (sans passer par le navigateur)

Le test le plus fiable : essayer de créer un fichier en tant que l’utilisateur du serveur web. Sur un VPS, vous pouvez simuler l’utilisateur web (ex : www-data). Si vous n’avez pas cet accès, passez au test via WordPress (plus bas).

# Test en tant que www-data (adaptez)
# Crée un fichier de test puis le supprime
sudo -u www-data bash -lc 'touch wp-content/uploads/.perm-test && rm -f wp-content/uploads/.perm-test && echo "OK: écriture possible"' 

Si vous voyez “Permission denied”, vous avez un problème de propriétaire ou de droits sur un parent (ex : wp-content) ou sur uploads.

3) Corriger wp-content et uploads de façon ciblée

Quand je dépanne, je corrige rarement “tout le WordPress” en premier. Je commence par la zone qui casse : uploads.

# Répertoires wp-content et uploads en 755
chmod 755 wp-content
chmod 755 wp-content/uploads

# Assurer que tout ce qui est sous uploads est cohérent
find wp-content/uploads -type d -exec chmod 755 {} ;
find wp-content/uploads -type f -exec chmod 644 {} ;

Ensuite, si nécessaire, je corrige le propriétaire sur uploads uniquement (moins risqué).

# Exemple : donner uploads à l'utilisateur web (adaptez)
sudo chown -R www-data:www-data wp-content/uploads

4) WordPress, Divi 5, Elementor, Avada : dossiers “cachés” qui ont besoin d’écriture

Sans entrer dans l’UI (vous m’avez demandé du code/commandes), voici ce que je vois souvent :

• Elementor écrit des fichiers CSS dans wp-content/uploads/elementor/css/.
• Divi et certains setups de Divi 5 écrivent des caches/ressources sous wp-content/ (selon modules et optimisation).
• Avada peut générer des fichiers et caches sous wp-content/uploads/ et wp-content/cache/ selon configuration.

Si un builder “perd” son CSS, ce n’est pas forcément un bug du builder : c’est parfois un dossier non inscriptible. La correction est la même : propriétaire cohérent + permissions 755/644.

Étape 4 : Cas particuliers (NFS, Docker, hébergement mutualisé, cache serveur)

Mutualisé : pas de chown, seulement chmod

Sur mutualisé, chown est généralement interdit. Si vos fichiers appartiennent au mauvais user (ex : après extraction via un outil serveur), vous ne pourrez pas réparer vous-même. Dans ce cas :

• remettez 755 dossiers / 644 fichiers ;
• demandez au support de “réattribuer le propriétaire” au user de votre compte.

NFS / volumes réseau : permissions “correctes” mais écriture impossible

Sur NFS, vous pouvez voir des droits qui semblent bons, mais les écritures échouent à cause de root_squash ou d’UID/GID incohérents entre machines. Symptôme typique : Permission denied alors que ls -l paraît correct.

Vérifiez les UID/GID :

id
stat -c "%U %G %u %g %a %n" wp-content/uploads

Si %u et %g ne correspondent pas à l’utilisateur PHP sur la machine qui écrit, alignez les UID/GID (c’est de l’admin système, pas WordPress).

Docker : attention aux volumes et à l’utilisateur du conteneur

En Docker, le conteneur PHP peut tourner en www-data (UID 33) alors que les fichiers montés depuis l’hôte appartiennent à un autre UID. Résultat : uploads cassés.

Dans le conteneur :

# Voir l'utilisateur et les droits depuis le conteneur
whoami
id
ls -ld wp-content/uploads

La correction peut nécessiter un chown côté hôte ou une configuration de l’utilisateur du conteneur (selon votre image). Ne “réparez” pas en 777 : vous masquez juste le vrai problème.

Cache serveur et permissions : faux positifs

J’ai déjà vu un site où les uploads étaient réparés, mais l’admin affichait encore une erreur car :

• un cache objet (Redis) conservait une valeur erronée de chemin ;
• ou un cache page servait une page d’erreur ancienne ;
• ou le navigateur gardait un CSS builder cassé.

Après correction, purge :

# Purger les caches WordPress si un plugin expose wp cache flush
wp cache flush || true

# Si vous utilisez Redis Object Cache (plugin), parfois :
wp redis flush --help 2>/dev/null || true

Fichiers de configuration complets

Le sujet est “permissions”, mais certains réglages serveur empêchent aussi l’écriture ou augmentent le risque si un attaquant arrive à déposer un fichier dans uploads. Je vous donne donc des configurations “prêtes à copier-coller” orientées sécurité : empêcher l’exécution de PHP dans uploads et renforcer quelques en-têtes.

.htaccess (Apache) : bloquer l’exécution de PHP dans uploads

À placer dans wp-content/uploads/.htaccess (créez le fichier). Cela réduit fortement l’impact d’une compromission qui déposerait un .php dans uploads.

# Créer/écraser le .htaccess dans uploads
cat > wp-content/uploads/.htaccess <<'HTACCESS'
# Sécurité : empêcher l'exécution de scripts dans uploads
# Compatible Apache (WordPress 6.9.4+)
<IfModule mod_php.c>
  php_flag engine off
</IfModule>

<IfModule mod_mime.c>
  RemoveHandler .php .phtml .php3 .php4 .php5 .php7 .phps
  RemoveType .php .phtml .php3 .php4 .php5 .php7 .phps
</IfModule>

<FilesMatch ".(php|phtml|php3|php4|php5|php7|phps)$">
  Require all denied
</FilesMatch>
HTACCESS

nginx.conf (server block) : bloquer PHP dans wp-content/uploads

À intégrer dans votre server { ... } Nginx. Le principe : refuser tout .php sous /wp-content/uploads/. C’est une mesure que j’active systématiquement en prod.

# Exemple de snippet Nginx à inclure dans server { }
# Adaptez les chemins selon votre config fastcgi
cat > /etc/nginx/snippets/wp-block-php-uploads.conf <<'NGINX'
# Sécurité : bloquer l'exécution de PHP dans uploads
location ~* ^/wp-content/uploads/.*.(php|phtml|php3|php4|php5|php7|phps)$ {
    deny all;
    return 403;
}
NGINX

Ensuite, incluez-le dans votre vhost :

# Exemple : dans votre server block
# include /etc/nginx/snippets/wp-block-php-uploads.conf;

# Tester et recharger Nginx
nginx -t && systemctl reload nginx

wp-config.php : désactiver l’éditeur de fichiers (réduction de surface)

Ce n’est pas une permission Unix, mais ça évite qu’un compte admin compromis édite des fichiers depuis l’admin. Ajoutez dans wp-config.php, au-dessus de “That’s all”.

<?php
// Sécurité : désactiver l'éditeur de fichiers dans l'admin WordPress
// Réduit l'impact si un compte admin est compromis
define('DISALLOW_FILE_EDIT', true);

Référence : developer.wordpress.org – wp-config.php.

php.ini (ou override PHP-FPM) : durcir les uploads (taille, temps)

Ces réglages n’affectent pas les permissions, mais évitent des échecs d’upload “silencieux” confondus avec un problème de chmod. Exemple minimal.

# Exemple de fichier php.ini (ou extrait à reporter dans votre conf PHP)
cat > /etc/php/8.3/fpm/conf.d/99-wp-uploads.ini <<'PHPINI'
; Réglages utiles pour uploads WordPress
; Adaptez selon votre serveur (PHP 8.1+)
file_uploads = On
upload_max_filesize = 64M
post_max_size = 64M
max_execution_time = 120
max_input_time = 120
memory_limit = 256M
PHPINI

# Recharger PHP-FPM (adaptez la version)
systemctl reload php8.3-fpm

Référence : php.net – directives php.ini.

Vérification

Vous voulez une validation qui ne dépend pas d’un cache navigateur. Voici une séquence de tests “serveur”.

1) Vérifier permissions et propriétaires avec stat

# Afficher droits + propriétaire/groupe sur les dossiers clés
stat -c "%a %U:%G %n" wp-content wp-content/uploads

# Vérifier un échantillon de fichiers dans uploads
find wp-content/uploads -maxdepth 2 -type f -print0 | xargs -0 -n 5 stat -c "%a %U:%G %n" | head -n 20

2) Vérifier que WordPress peut écrire (test WP-CLI)

WP-CLI permet de déclencher une action qui écrit dans uploads. Le plus simple : importer un fichier image présent sur le serveur (même un petit fichier). Exemple : créer un fichier factice n’est pas suffisant pour WordPress, il faut un vrai média. Si vous avez une image test test.jpg :

# Exemple : importer un média via WP-CLI (écrit dans uploads + DB)
# Remplacez /chemin/vers/test.jpg
wp media import /chemin/vers/test.jpg --title="Test permissions uploads" --porcelain

Si la commande renvoie un ID d’attachement, WordPress a pu écrire.

3) Vérifier côté HTTP (Nginx/Apache) que PHP est bien bloqué dans uploads

Créez un fichier test.php dans uploads (sur un staging, pas en prod), puis vérifiez que le serveur renvoie 403/404, pas une exécution.

# Créer un fichier PHP de test (à supprimer ensuite)
echo '<?php echo "NE DOIT PAS S'EXECUTER";' > wp-content/uploads/test.php

# Tester via curl (adaptez le domaine)
curl -I https://example.com/wp-content/uploads/test.php

# Nettoyer
rm -f wp-content/uploads/test.php

Si ça ne marche pas

Quand ça échoue encore après un “755/644”, je procède toujours dans cet ordre : logs, utilisateur PHP, ACL/SELinux, puis seulement WordPress.

Diagnostic rapide (table)

Symptôme	Cause probable	Vérification	Solution
Upload impossible, message “Impossible de créer le répertoire”	Propriétaire incohérent (root, mauvais user)	ls -ld wp-content/uploads	chown -R userweb:userweb wp-content/uploads (ou support mutualisé)
Uploads OK en SSH, KO via WordPress	PHP-FPM tourne sous un autre user que prévu	Lire pool FPM (user=)	Aligner propriétaire/groupe sur l’utilisateur du pool
Droits OK, mais “Permission denied” persiste	SELinux/AppArmor/ACL	getenforce, getfacl	Corriger contexte SELinux ou ACL
CSS Elementor/Divi manquant	Dossier de génération non inscriptible	ls -ld wp-content/uploads/elementor	Fixer propriétaire + 755 dossiers, purge cache
Après correction, erreur “reste” dans l’admin	Cache page/objet ou navigateur	wp cache flush, test en navigation privée	Purger caches + régénérer assets builder

1) Lire les logs serveur (vous gagnerez du temps)

Sur Nginx :

tail -n 200 /var/log/nginx/error.log

Sur Apache :

tail -n 200 /var/log/apache2/error.log 2>/dev/null || tail -n 200 /var/log/httpd/error_log

Sur PHP-FPM :

# Chemins variables selon distro/version
tail -n 200 /var/log/php8.3-fpm.log 2>/dev/null || true
journalctl -u php8.3-fpm -n 200 --no-pager 2>/dev/null || true

2) Vérifier SELinux (si applicable)

Sur certaines distros, SELinux bloque l’écriture même si chmod/chown sont corrects. Vérifiez :

getenforce 2>/dev/null || echo "SELinux non présent"

Si c’est Enforcing, inspectez les contextes :

# Voir le contexte SELinux
ls -ldZ wp-content wp-content/uploads 2>/dev/null || true

La correction SELinux dépend de votre politique. Sur un WordPress standard, on voit souvent un besoin de contexte type httpd_sys_rw_content_t sur uploads. Ne changez pas ça “en aveugle” sur un serveur d’entreprise, validez avec votre admin système.

3) Vérifier les ACL (Access Control Lists)

Les ACL peuvent surcharger chmod. Exemple : un mask ACL peut retirer l’écriture même si vous voyez 755.

getfacl -p wp-content/uploads 2>/dev/null | sed -n '1,80p'

4) Vérifier que vous n’avez pas “réparé” sur le mauvais chemin

Cas réel : le site a UPLOADS redéfini, mais vous corrigez wp-content/uploads. Vérifiez dans wp-config.php :

grep -n "UPLOADS" wp-config.php || true

Pièges et erreurs courantes

Voici les erreurs que je vois le plus souvent quand quelqu’un “corrige les permissions” sur WordPress.

Erreur	Cause	Solution
Mettre 777 sur wp-content ou uploads	On cherche un “fix rapide”	Revenir à 755/644, corriger le propriétaire (ou groupe + setgid)
Changer les droits sur tout /var/www	Commande lancée trop haut (mauvais dossier)	Revenir à la racine WordPress, limiter à /var/www/site
Oublier que chown est impossible en mutualisé	Droits insuffisants	Faire chmod propre + contacter le support pour le propriétaire
Corriger wp-content/uploads mais pas ses parents	wp-content ou racine non traversable	Vérifier aussi wp-content et le chemin complet avec namei -l
Tester en production sans sauvegarde	Pression / urgence	Archive tar avant, ou staging
Se fier à un vieux tutoriel (permissions “exotiques”)	Copier-coller d’anciennes pratiques	Rester sur 755/644 + propriétaire cohérent (WordPress 6.9.4, PHP 8.1+)
CSS/JS builder manquant malgré permissions OK	Cache non purgé, génération bloquée ailleurs	Purger cache, vérifier dossiers spécifiques (ex: uploads/elementor)

Commande de vérification du chemin complet (souvent oubliée)

Si un dossier parent n’a pas le droit “x” (traverser), l’écriture échoue. La commande namei montre les droits de chaque segment du chemin.

# Vérifier chaque niveau du chemin
namei -l /var/www/site/wp-content/uploads

Sécurité serveur

Les permissions ne sont pas qu’un détail technique : c’est une barrière de sécurité.

1) Empêcher l’exécution dans uploads (Apache/Nginx)

Vous l’avez fait plus haut via .htaccess ou un bloc Nginx. C’est une des protections les plus rentables sur WordPress.

2) Éviter que PHP puisse écrire partout

Sur un serveur bien tenu, PHP ne devrait écrire que là où c’est nécessaire (uploads, cache, upgrade). Si vous mettez tout le site en propriétaire www-data et que vous laissez l’admin installer des plugins, vous augmentez l’impact d’une faille plugin.

La stratégie “déployeur + groupe web + setgid” est souvent un bon compromis (voir étape 2).

3) Permissions recommandées : rappel

• Dossiers : 755 (ou 750 si vous maîtrisez les groupes)
• Fichiers : 644 (ou 640)
• wp-config.php : 600/640 selon votre modèle d’accès

4) Vérifier que WordPress n’affiche pas les répertoires

Si l’indexation de répertoire est activée, un visiteur peut lister des fichiers dans certains dossiers. Côté Apache, on désactive souvent Options Indexes. Côté Nginx, c’est généralement off par défaut, mais vérifiez vos conf.

Ressources

• WordPress.org – Changing File Permissions
• developer.wordpress.org – wp-config.php (constantes et réglages)
• developer.wordpress.org – WP-CLI commands (référence)
• GitHub – WordPress/wordpress-develop (code source)
• php.net – php.ini directives (upload_max_filesize, post_max_size…)
• core.trac.wordpress.org – suivi des tickets du core WordPress

FAQ

Quel chmod pour wp-content et uploads sur WordPress 6.9.4 ?

Dans la majorité des cas : wp-content en 755, wp-content/uploads en 755, fichiers en 644. Ensuite, assurez-vous que le propriétaire permet l’écriture à PHP là où nécessaire.

Pourquoi mon upload échoue alors que uploads est en 777 ?

Deux causes fréquentes : (1) vous écrivez dans le mauvais dossier (chemin uploads personnalisé), (2) un contrôle externe bloque (SELinux, ACL, montage NFS, quota disque). 777 ne contourne pas SELinux/ACL et ne règle pas un mauvais chemin.

Dois-je donner www-data propriétaire de tout le site ?

Ça marche, mais c’est rarement le meilleur choix sécurité. Si un plugin vulnérable permet une écriture, il pourra modifier plus de fichiers. Je préfère : un user “deploy” propriétaire, et seulement certains dossiers en écriture pour le groupe web.

Je suis sur mutualisé, je ne peux pas faire chown. Je fais quoi ?

Appliquez 755/644 via FTP/SFTP si possible, puis demandez au support de réattribuer le propriétaire au user de votre compte. Sans propriétaire correct, vous pouvez rester bloqué.

Quels dossiers doivent être inscriptibles pour Elementor / Divi / Avada ?

Le plus courant : sous wp-content/uploads/ (ex : uploads/elementor/ pour Elementor). Certains caches peuvent être sous wp-content/cache/. La règle reste : propriétaire correct + droits raisonnables, pas 777.

Comment tester sans passer par l’admin WordPress ?

Utilisez WP-CLI : wp media import avec un fichier réel, ou testez l’écriture en tant qu’utilisateur web avec sudo -u www-data touch ....

Est-ce que 750/640 est mieux que 755/644 ?

Oui si vous maîtrisez précisément le couple user/groupe et que le serveur web n’a pas besoin d’accès “autres”. Sur des hébergements simples, 755/644 évite des blocages inattendus. 750/640 est plus strict mais demande une config propre des groupes.

J’ai corrigé les permissions, mais les images ne s’affichent pas

Vérifiez (1) les URLs (HTTP vs HTTPS), (2) les droits de lecture (fichiers en 644), (3) les règles Nginx/Apache, (4) un CDN/cache. Côté serveur, un curl -I sur une image dans uploads doit renvoyer 200.

Quelle commande rapide pour “remettre propre” tout WordPress ?

Depuis la racine : dossiers en 755 et fichiers en 644 via find. Puis corrigez le propriétaire si nécessaire. Évitez de lancer ça au mauvais endroit (ex : /var/www entier).

find . -type d -exec chmod 755 {} ;
find . -type f -exec chmod 644 {} ;

Est-ce que WordPress a une fonction interne pour réparer les permissions ?

Non, pas une commande magique côté core. WordPress s’appuie sur le système de fichiers et l’utilisateur PHP. Vous pouvez diagnostiquer via WP-CLI, mais la correction se fait côté OS (chmod/chown/SELinux/ACL).

Que faire si un vieux tutoriel recommande 777 pour “fixer les mises à jour” ?

Ne le faites pas. Sur WordPress 6.9.4, la bonne approche est : propriétaire cohérent, dossiers d’écriture limités, et si nécessaire config FTP/SSH pour les mises à jour (selon hébergement). 777 est un contournement dangereux, pas une solution.