Credit : Logo officiel
Résoudre les problèmes de permissions fichiers sous Linux
Resoudre les problemes de permissions fichiers sous Linux
Jeudi dernier, un client e-commerce sur PrestaShop 8.1 m'appelle parce que ses uploads d'images ne fonctionnent plus depuis qu'il a migre son site d'un autre hebergeur vers IONOS. Aucun message d'erreur dans le BO PrestaShop, juste un "impossible d'uploader" silencieux. Verification SSH : tous les fichiers appartiennent a root au lieu de son user FTP. Resultat le serveur web ne peut ni lire ni ecrire dans img/. Un chown -R user:user plus tard, tout fonctionne. Probleme classique apres migration, et 100% des cas sont des permissions.
Erreur 403 Forbidden ? Plugin WordPress qui ne peut pas s'updater ? Upload qui echoue silencieusement ? Dans 80% des cas, c'est les permissions Linux. Apres avoir traite ce probleme sur des centaines de serveurs IONOS, voici ma methode systematique.
Comprendre les permissions Linux
Avant de balancer des chmod 755 partout, faut comprendre ce que tu modifies. Les permissions Linux se lisent en trois groupes de trois bits :
- User (proprietaire) : les droits du proprietaire du fichier
- Group : les droits des membres du groupe associe
- Other : les droits de tous les autres utilisateurs
Chaque groupe a trois bits : r (read = 4), w (write = 2), x (execute = 1). Quand tu vois 755, c'est :
- 7 = 4+2+1 (rwx) pour le proprietaire
- 5 = 4+0+1 (r-x) pour le groupe
- 5 = 4+0+1 (r-x) pour les autres
Pour un dossier, le bit x signifie pas "executer" mais "traverser" (entrer dans le dossier). Sans le x sur un dossier, meme avec r, tu peux pas voir le contenu.
Diagnostiquer le probleme
La premiere chose a faire avant de toucher aux permissions, c'est de verifier le proprietaire des fichiers. Souvent le probleme est la, pas dans les bits :
ls -la /home/htdocs/web/
La colonne 3 c'est le proprietaire (user), la colonne 4 c'est le groupe. Sur les serveurs IONOS, le proprietaire doit correspondre a ton identifiant FTP (du genre u123456789). Si c'est root, apache, www-data apres une migration, t'as un probleme.
Pour trouver tous les fichiers qui n'appartiennent pas au bon user :
find . ! -user $(stat -c %U .) -ls
Ca compare le proprietaire de chaque fichier avec celui du repertoire courant. Tres pratique pour reperer les fichiers parasites.
Sur les hebergements mutualises IONOS, si le proprietaire ne correspond pas a ton FTP apres une restauration ou une migration, contacte le support pour qu'on corrige le ownership avec les droits root. Tu peux pas le faire toi-meme sur du mutualise.
Les permissions standard : 755 et 644
La regle universelle pour un site web sur serveur dedie ou VPS :
- Dossiers : 755 (rwxr-xr-x) -- le proprietaire peut tout faire, les autres lisent et traversent
- Fichiers : 644 (rw-r--r--) -- le proprietaire lit/ecrit, les autres lisent
Pour appliquer ces permissions d'un coup sur tout un site :
find /home/htdocs/web -type d -exec chmod 755 {} \;
find /home/htdocs/web -type f -exec chmod 644 {} \;
Le find ... -exec itere sur chaque fichier ou dossier et applique le chmod. Plus rapide avec xargs :
find /home/htdocs/web -type d -print0 | xargs -0 chmod 755
find /home/htdocs/web -type f -print0 | xargs -0 chmod 644
Le -print0 et -0 gerent correctement les noms de fichiers avec espaces ou caracteres speciaux.
Le cas particulier du mutualise IONOS
Attention, sur un hebergement mutualise IONOS, les permissions standards 755/644 ne fonctionnent pas correctement. On voit souvent des clients qui appliquent ces valeurs et qui se retrouvent avec des problemes bizarres : impossibilite d'ecrire dans certains dossiers, fichiers "non trouves" alors qu'ils existent.
La raison est architecturale : sur un mutualise, le serveur web (Apache/Nginx) tourne sous un utilisateur different de ton compte FTP. Il accede a tes fichiers via le groupe "other" (les trois derniers bits). Si tu ouvres trop sur "group", t'exposes tes fichiers aux autres clients du mutu. Du coup la bonne config c'est :
- Dossiers : 705 (rwx---r-x)
- Fichiers : 604 (rw----r--)
find /home/htdocs/web -type d -exec chmod 705 {} \;
find /home/htdocs/web -type f -exec chmod 604 {} \;
Le 0 au milieu (groupe) supprime tous les droits du groupe. Plus securise sur un environnement partage.
Symptomes courants et diagnostic
Voici les symptomes que je rencontre le plus souvent et leur cause typique :
| Symptome | Cause probable | Fix |
|---|---|---|
| Erreur 403 Forbidden | Dossier sans permission d'execution (pas de x) | chmod 755 /chemin/dossier |
| Impossible d'uploader des images WordPress | wp-content/uploads pas accessible en ecriture |
chmod 755 wp-content/uploads -R |
| Plugin ne peut pas se mettre a jour | Fichiers du plugin appartiennent a root | chown -R user:user wp-content/plugins |
| Page blanche apres migration | .htaccess avec mauvaises permissions |
chmod 644 .htaccess |
| Cron WordPress marche pas | wp-cron.php pas lisible par le serveur web |
chmod 644 wp-cron.php |
| Erreur 500 sur PrestaShop | Cache pas accessible en ecriture | chmod -R 755 var/cache/ |
| Connexion BDD echoue | wp-config.php trop restreint | chmod 604 wp-config.php (mutualise) |
| Theme custom invisible | Dossier theme en 600 au lieu de 755 | chmod 755 wp-content/themes/montheme |
Cas specifique : wp-config.php
Le wp-config.php contient les identifiants de ta base de donnees, les cles de salage, et toute la config sensible. Il merite une attention particuliere.
Sur un serveur dedie ou VPS :
chmod 600 wp-config.php
600 = lecture/ecriture par le proprietaire uniquement. Personne d'autre y a acces, meme pas le serveur web. Mais ca marche que si PHP tourne sous le meme user que le proprietaire du fichier (typiquement avec PHP-FPM bien configure).
Sur un mutualise IONOS, utilise plutot 604 :
chmod 604 wp-config.php
Sinon le serveur web (qui est dans "other") pourra pas lire le fichier et tu auras une erreur de connexion BDD.
Meme principe pour .htaccess et .htpasswd :
chmod 604 .htaccess .htpasswd
Ce qu'il ne faut JAMAIS faire
Le pire conseil que je vois sur internet :
# NON NON NON - JAMAIS
chmod -R 777 /home/htdocs/web
777 = tout le monde peut lire, ecrire ET executer tous tes fichiers. C'est une faille de securite massive. Sur un mutualise, ca permet a n'importe quel autre client du serveur de lire ton wp-config.php et de chopper tes credentials BDD. Sur un dedie, c'est moins grave mais quand meme catastrophique en cas d'intrusion : un attaquant qui compromet un seul fichier PHP a tous les droits sur tout ton site.
Si tu vois un tuto qui dit de mettre 777, ferme l'onglet et lis autre chose. C'est le signe que l'auteur ne sait pas ce qu'il fait.
Le bit setgid pour les dossiers collaboratifs
Un truc utile mais peu connu : le bit setgid sur un dossier force tous les nouveaux fichiers crees a herite du groupe du dossier parent. Pratique pour les dossiers partages entre plusieurs users.
chmod g+s /home/htdocs/web/uploads
chmod 2775 /home/htdocs/web/uploads
Le 2 devant 775 active le setgid. Tout fichier cree dans uploads aura automatiquement le bon groupe, peu importe quel user le cree.
Les ACL : permissions avancees
Quand les permissions classiques ne suffisent pas (besoin de donner des droits a plusieurs groupes par exemple), passe aux ACL Linux :
# Donner les droits read/write au groupe www-data sur uploads
setfacl -R -m g:www-data:rwx /home/htdocs/web/wp-content/uploads
# Verifier les ACL
getfacl /home/htdocs/web/wp-content/uploads
Les ACL sont supportees par defaut sur les VPS IONOS recents (Debian 12, Ubuntu 22.04). Sur les mutualises, c'est variable.
Verification post-correction
Apres avoir applique tes nouvelles permissions, verifie le resultat :
stat -c '%a %U %G %n' wp-config.php .htaccess index.php
Ca affiche les permissions en octal, le proprietaire, le groupe et le nom. Pratique pour un controle rapide.
Pour un audit complet du site :
find /home/htdocs/web -type f -perm -o+w -ls
Ca liste tous les fichiers ecrivables par "other". Sur un site bien configure, ca devrait rien remonter (sauf les dossiers d'upload).
Erreurs courantes et leur fix
"Operation not permitted" sur chmod
T'es pas le proprietaire du fichier. Soit tu connais le mot de passe root et tu fais sudo, soit tu demandes au support de corriger le ownership.
chmod recursif tres lent
Sur des sites avec des dizaines de milliers de fichiers (gros WooCommerce avec uploads), le find peut prendre 10-15 minutes. Utilise GNU parallel pour paralleliser :
find . -type f -print0 | parallel -0 chmod 644
Permission OK mais l'erreur 403 persiste
Verifie aussi la presence d'un .htaccess qui bloque :
cat /home/htdocs/web/.htaccess
Cherche des lignes Deny from all ou Require all denied.
umask qui pourrit tout
Si tes nouveaux fichiers crees ont systematiquement de mauvaises permissions, c'est ton umask. Verifie :
umask
La valeur courante devrait etre 022 (donnant 644 sur fichiers et 755 sur dossiers). Modifie dans ~/.bashrc :
umask 022
Mode FTP qui force 600
Certains clients FTP ont une option qui force toutes les uploads en 600. Verifie les preferences de FileZilla ou autre. Sur IONOS, on a deja eu le cas d'un client dont tous les fichiers uploades etaient 600 a cause d'une option FTP.
Script de correction automatique
Voila un script que je file aux clients pour corriger les permissions d'un coup sur leur WordPress :
#!/bin/bash
# fix-wp-permissions.sh
WP_PATH="/home/htdocs/web"
WP_USER="u123456789"
# Ownership
chown -R ${WP_USER}:${WP_USER} ${WP_PATH}
# Dossiers en 755
find ${WP_PATH} -type d -exec chmod 755 {} \;
# Fichiers en 644
find ${WP_PATH} -type f -exec chmod 644 {} \;
# wp-config plus restrictif
chmod 600 ${WP_PATH}/wp-config.php
# Uploads en ecriture pour le serveur web
chmod -R 775 ${WP_PATH}/wp-content/uploads
echo "Permissions corrigees pour ${WP_PATH}"
A executer en root sur un VPS, ou a faire executer par le support sur un mutualise.
Pour aller plus loin
- Permissions Linux : chmod chown ACL en détail
- Sécuriser WordPress : guide complet anti-hack
- Diagnostiquer les erreurs 500 sur hébergement mutualisé
- Hardening Linux : sécuriser son serveur
- Logs Linux : où chercher et comment lire
Permissions, le langage que parle Linux
Maitriser les permissions Linux c'est maitriser une partie fondamentale du systeme. C'est pas glamour, c'est pas excitant, mais c'est ce qui differencie le sysadmin qui sait ce qu'il fait du gars qui copie-colle des chmod 777 trouves sur StackOverflow. Prends le temps de comprendre ce que tu fais, evite les solutions miracles trop ouvertes, et garde toujours un principe en tete : minimum de droits necessaires.
Si t'as des doutes, contacte le support. Sur IONOS on prefere passer 10 minutes a verifier avec toi plutot que de devoir nettoyer un site hacke parce que les permissions etaient ouvertes a tous vents. Et la prochaine fois qu'un upload echoue mysterieusement sur un de tes sites, tu sauras ou regarder en premier.