« Permission denied » sous Linux : comprendre et corriger l’erreur

Vous lancez un script, copiez un fichier ou ouvrez une connexion SSH, et le terminal répond « Permission denied ». L’erreur est normale : Linux protège ses fichiers. Il suffit de comprendre qui a le droit de faire quoi, puis d’ajuster le strict nécessaire.

Situations courantes et commandes

Lire les droits avec ls -l

Tapez ls -l fichier. Vous obtenez une ligne du type -rwxr-xr-- 1 anne equipe 1204 nov. 3 10:12 script.sh. Les dix premiers caractères se lisent ainsi :

• le premier indique le type : - fichier, d dossier, l lien ;
• puis trois groupes de trois lettres : droits du propriétaire (anne), du groupe (equipe) et des autres ;
• r = lecture (4), w = écriture (2), x = exécution (1), - = absent.

Ainsi rwxr-xr-- correspond à 754 en notation octale. Pour un dossier, x signifie « avoir le droit d’y entrer » : sans lui, vous obtenez aussi « Permission denied ».

Script non exécutable : chmod +x

Si ./script.sh répond « Permission denied » alors que le fichier existe, c’est presque toujours l’exécution qui manque. La correction :

1. Vérifiez avec ls -l script.sh : aucun x n’apparaît.
2. Ajoutez le droit : chmod +x script.sh.
3. Relancez avec ./script.sh.

Astuce : bash script.sh lance un script shell même sans droit d’exécution, car c’est alors bash qui le lit.

Fichier d’un autre utilisateur : sudo ou chown

Pour une modification ponctuelle d’un fichier système, préfixez par sudo : sudo nano /etc/hosts. Attention aux redirections : sudo echo "x" > /etc/fichier échoue, car la redirection est exécutée par votre shell et non par sudo ; utilisez echo "x" | sudo tee /etc/fichier.

Si un dossier de votre répertoire personnel est devenu la propriété de root, souvent après un sudo malvenu, rendez-le-vous : sudo chown -R $USER:$USER ~/projet. Relisez la commande avant de valider : un chown -R mal ciblé sur / peut abîmer le système.

Pourquoi éviter chmod 777

chmod 777 donne lecture, écriture et exécution à tous les utilisateurs et à tous les programmes. Sur un serveur, c’est une faille ; sur un poste, c’est une mauvaise habitude qui masque la vraie cause. Mieux vaut donner le droit précis : chmod u+x pour exécuter, chmod 644 pour un fichier ordinaire, chmod 755 pour un dossier ou un programme.

Permission denied en SSH

Le message « Permission denied (publickey) » a plusieurs origines. Vérifiez dans l’ordre :

• le dossier ~/.ssh en 700 et la clé privée en 600 : SSH refuse une clé lisible par d’autres ;
• le bon nom d’utilisateur, et la bonne clé indiquée avec ssh -i ;
• la clé publique présente dans ~/.ssh/authorized_keys du serveur, lui-même en 600 ;
• le détail du refus avec ssh -v utilisateur@serveur.

Pour monter un service sur le même principe côté serveur, voyez par exemple l’installation d’un serveur FTP ProFTPD sous Linux, où les droits des dossiers jouent aussi un rôle central.

Disques montés et noexec

Un disque NTFS, exFAT ou une clé USB monté avec l’option noexec interdit l’exécution des programmes, quel que soit le chmod. Les partitions NTFS ne gardent pas non plus les droits Linux. Contrôlez avec mount | grep noexec. La solution propre : copier le script dans votre dossier personnel, sur un système de fichiers Linux, plutôt que de modifier le montage.

Cas pratique : un script de sauvegarde

Hugo télécharge sauvegarde.sh dans ~/Téléchargements. Le lancement donne « Permission denied ». Il tape ls -l : -rw-r--r--, donc pas de x. Il exécute chmod +x sauvegarde.sh et le script démarre, mais il échoue ensuite à écrire dans /var/backups. Au lieu de modifier ce dossier système, il relance avec sudo ./sauvegarde.sh après avoir relu le contenu du script.

À lire aussi : les erreurs Linux les plus fréquentes, débloquer apt (dpkg lock), « Unable to locate package » et configurer plusieurs écrans depuis le terminal.

Questions fréquentes