Liens physiques et symboliques sous Linux

Un lien donne un second nom à un fichier, sans le dupliquer. Linux en propose deux sortes, qui se ressemblent à l'usage mais n'ont rien de commun en interne : le lien physique, un vrai nom supplémentaire pour les mêmes données, et le lien symbolique, un simple panneau indicateur qui contient un chemin. Ce guide montre comment créer les deux avec ln, comment les distinguer par leur inode, comment repérer un lien brisé, et surtout comment éviter la commande qui efface silencieusement le contenu de la cible. Toutes les sorties viennent d'un test sur AlmaLinux 10.

Ce que vous allez apprendre

Créer un lien physique et un lien symbolique avec ln
Distinguer les deux grâce à l'inode et au compteur de liens
Choisir lequel utiliser selon le besoin
Repérer et réparer un lien symbolique brisé
Éviter les quatre pièges qui font perdre des données ou du temps

Prérequis

Savoir naviguer dans l'arborescence (ls, cd, rm)
Comprendre la différence entre chemin absolu et relatif
Un shell, aucun privilège particulier

Un fichier n'est pas son nom

Pour comprendre les liens, il faut d'abord défaire une idée intuitive : sous Linux, un fichier et son nom sont deux choses séparées.

Les données, les permissions, les dates et le propriétaire vivent dans une structure appelée inode, identifiée par un numéro unique sur le système de fichiers. Le nom, lui, n'est qu'une entrée dans un répertoire, qui pointe vers ce numéro d'inode.

Un répertoire, c'est donc un annuaire : il associe des noms à des numéros. Rien n'interdit à deux noms de désigner le même numéro, et c'est exactement ce qu'est un lien physique.

ls -li rapport.txt

8591538 -rw-r--r--. 1 ansible ansible 17 Jul 23 10:04 rapport.txt

La première colonne, ajoutée par l'option -i, est le numéro d'inode. Le chiffre juste après les permissions, ici 1, est le compteur de liens : le nombre de noms qui désignent cet inode. Ces deux valeurs sont la clé de tout ce qui suit.

Le lien physique : un nom de plus

Un lien physique (hard link) ajoute une entrée d'annuaire vers un inode existant. Il ne copie rien.

echo "contenu original" > rapport.txt
ln rapport.txt rapport-copie.txt
ls -li rapport.txt rapport-copie.txt

8591538 -rw-r--r--. 2 ansible ansible 17 Jul 23 10:04 rapport-copie.txt
8591538 -rw-r--r--. 2 ansible ansible 17 Jul 23 10:04 rapport.txt

Deux observations à faire ensemble. Le numéro d'inode est identique (8591538) : ce n'est pas une copie, c'est le même fichier. Et le compteur de liens est passé de 1 à 2, parce que deux noms le désignent désormais.

La conséquence suit logiquement : modifier l'un modifie l'autre, puisqu'il n'y a qu'un seul fichier.

echo "ligne ajoutee" >> rapport-copie.txt
cat rapport.txt

contenu original
ligne ajoutee

Et supprimer un nom ne détruit rien tant qu'il en reste un autre :

rm rapport.txt
ls -li rapport-copie.txt
cat rapport-copie.txt

8591538 -rw-r--r--. 1 ansible ansible 31 Jul 23 10:04 rapport-copie.txt
contenu original
ligne ajoutee

Le compteur est retombé à 1, les données sont intactes. C'est ce qui explique le fonctionnement réel de rm : la commande retire un nom et décrémente le compteur. Les données ne sont libérées que lorsque le compteur atteint zéro, et qu'aucun processus ne tient le fichier ouvert.

Retrouver tous les noms d'un même fichier

Puisque plusieurs noms peuvent coexister, autant savoir les retrouver. find sait chercher par numéro d'inode :

stat -c 'liens=%h inode=%i' a.txt
find ~/lab-liens -inum 8591547

liens=3 inode=8591547
/home/ansible/lab-liens/a.txt
/home/ansible/lab-liens/b.txt
/home/ansible/lab-liens/c.txt

C'est le réflexe à avoir quand du et df semblent se contredire : un fichier compté plusieurs fois par du mais stocké une seule fois sur le disque est très souvent un lien physique.

Les deux limites du lien physique

Le lien physique a deux contraintes strictes, qui découlent directement de sa nature.

ln dossier dossier-lien

ln: dossier: hard link not allowed for directory

Pas de lien physique vers un répertoire. L'interdiction protège le système : des répertoires se pointant mutuellement créeraient des boucles infinies dans l'arborescence, que les outils de parcours ne sauraient pas traiter.

ln ~/rapport.txt /dev/shm/essai

ln: failed to create hard link '/dev/shm/essai' => '/home/ansible/rapport.txt':
Invalid cross-device link

Pas de lien physique entre deux systèmes de fichiers. Un numéro d'inode n'a de sens qu'à l'intérieur d'un système de fichiers donné : l'inode 8591538 de votre disque et celui d'une clé USB n'ont aucun rapport. Le message Invalid cross-device link est explicite une fois qu'on connaît la raison.

Le lien symbolique : un panneau indicateur

Un lien symbolique (symlink, ou lien souple) est un fichier à part entière, avec son propre inode, dont le contenu est simplement un chemin. Il s'agit d'un panneau qui dit « ce que tu cherches est là-bas ».

echo "donnees" > cible.txt
ln -s cible.txt raccourci.txt
ls -li cible.txt raccourci.txt

8591540 -rw-r--r--. 1 ansible ansible 8 Jul 23 10:04 cible.txt
8591541 lrwxrwxrwx. 1 ansible ansible 9 Jul 23 10:04 raccourci.txt -> cible.txt

Tout diffère du cas précédent. Les inodes sont différents (8591540 et 8591541), le type de fichier est l en tête des permissions, et ls -l affiche la flèche vers la destination. La taille de 9 octets n'est pas un hasard : c'est la longueur de la chaîne cible.txt.

Les liens symboliques lèvent les deux limites du lien physique : ils traversent les systèmes de fichiers et pointent vers des répertoires. C'est pourquoi ils sont, de très loin, les plus utilisés.

readlink affiche la destination enregistrée dans le lien, sans la suivre. C'est le contrôle à faire après chaque ln -s :

readlink raccourci.txt          # la cible telle qu'écrite
readlink -f raccourci.txt       # le chemin final, tous liens résolus

Le lien brisé

Comme le lien symbolique ne contient qu'un chemin, rien ne garantit que ce chemin existe. Supprimez la cible, et le lien devient brisé (dangling) :

rm cible.txt
ls -l raccourci.txt
cat raccourci.txt

lrwxrwxrwx. 1 ansible ansible 9 Jul 23 10:04 raccourci.txt -> cible.txt
cat: raccourci.txt: No such file or directory

Le lien est toujours là, ls l'affiche sans broncher, mais rien ne répond au bout. Deux tests permettent de faire la différence en script :

test -e raccourci.txt && echo "la cible existe" || echo "lien brise"
test -L raccourci.txt && echo "c'est bien un lien"

-e suit le lien et échoue si la cible manque ; -L teste l'existence du lien lui-même. Un lien brisé répond donc « non » au premier et « oui » au second, ce qui les distingue d'un fichier réellement absent.

Pour balayer une arborescence entière, find a un prédicat dédié :

find /opt -xtype l

-xtype l ne remonte que les liens dont la cible n'est pas un lien valide, c'est-à-dire les liens cassés. C'est la commande d'inventaire après une migration ou une désinstallation.

Physique ou symbolique : lequel choisir

En pratique, le choix se fait presque toujours en faveur du symbolique. Le tableau ci-dessous résume les propriétés qui décident.

Critère	Lien physique	Lien symbolique
Inode	le même que la cible	le sien, distinct
Vers un répertoire	impossible	possible
Vers un autre système de fichiers	impossible	possible
Si la cible est supprimée	les données survivent	le lien est brisé
Visible dans `ls -l`	indiscernable d'un fichier	flèche `->` et type `l`
Cas d'usage typique	sauvegardes, déduplication	versions courantes, raccourcis de configuration

Le motif le plus répandu en administration est le lien symbolique de version : un chemin stable qui pointe vers la version en cours, qu'on redirige lors d'une mise à jour sans toucher aux scripts qui l'utilisent.

ln -sfn /opt/app-2.4.1 /opt/app-courante

Les scripts référencent /opt/app-courante, et une mise à jour se résume à faire pointer le lien ailleurs. Notez l'option -n, dont la section suivante explique pourquoi elle n'est pas facultative.

Quatre pièges à connaître

Ces quatre comportements ne produisent aucune erreur explicite, ou un message qui induit en erreur. Ils méritent d'être vus une fois avant de les rencontrer en production.

`rm -r lien/` détruit le contenu de la cible

C'est le plus grave, parce qu'il perd des données en silence derrière un message rassurant. La combinaison en cause est précise : un lien symbolique vers un répertoire, une barre oblique finale, et l'option -r.

mkdir cible-dir && touch cible-dir/f1 cible-dir/f2
ln -s cible-dir lien-dir
rm -r lien-dir/

rm: cannot remove 'lien-dir/': Not a directory

Le message annonce un échec, le code de retour vaut 1, et pourtant :

ls cible-dir | wc -l

Les deux fichiers ont disparu. La barre oblique a fait suivre le lien à rm, qui a vidé le répertoire visé, puis a échoué en tentant de supprimer le lien lui-même, d'où le message. Le lien et le répertoire survivent, leur contenu non.

Les trois autres formes sont parfaitement inoffensives, mesurées sur le même montage :

Commande	Code de retour	Contenu de la cible
`rm lien-dir`	0	2 fichiers, intacts
`rm -r lien-dir`	0	2 fichiers, intacts
`rm lien-dir/`	1 (`Is a directory`)	2 fichiers, intacts
`rm -r lien-dir/`	1 (`Not a directory`)	0 fichier

La leçon pratique : ne mettez jamais de barre oblique finale sur un lien symbolique. Et si vous supprimez des liens dans un script, préférez la forme explicite qui ne peut pas déraper :

find /chemin -maxdepth 1 -type l -delete

`ln -sf` ne remplace pas un lien visant un répertoire

Le réflexe pour rediriger un lien existant est ln -sf. Il fonctionne pour un lien vers un fichier, et échoue silencieusement pour un lien vers un répertoire.

ln -s v1 courant
ln -sf v2 courant
readlink courant

v1

Le code de retour vaut 0, et pourtant courant pointe toujours vers v1. La commande a interprété courant comme le répertoire de destination et a créé un lien à l'intérieur de la cible :

ls v1

v2

L'option -n (--no-dereference) corrige le comportement en traitant courant comme un lien et non comme un répertoire :

ln -sfn v2 courant
readlink courant

v2

Retenez la forme ln -sfn comme forme par défaut pour rediriger un lien : elle est correcte dans tous les cas.

`chmod -h` sort en succès sans rien faire

Vous pourriez croire durcir un lien en modifiant ses permissions. Sous Linux, cela n'a aucun effet.

ls -l l.txt          # lrwxrwxrwx, comme tous les liens
chmod -h 600 l.txt
echo $?
stat -c %a l.txt

0
777

Le code de retour vaut 0, aucun message n'apparaît, et les droits n'ont pas bougé. La raison est simple : le noyau Linux ne consulte jamais les permissions d'un lien symbolique, seules comptent celles de la cible. L'option -h existe pour la portabilité vers d'autres Unix qui, eux, en tiennent compte.

Ce qui protège réellement, c'est donc de régler les droits de la cible, ou ceux du répertoire qui contient le lien.

`cp` sans `-d` copie la cible, pas le lien

Copier un lien symbolique ne donne pas un lien symbolique :

cp lien.txt copie.txt
test -L copie.txt && echo "lien" || echo "fichier regulier"

fichier regulier

cp a suivi le lien et copié le contenu de la cible. Pour préserver le lien en tant que tel, il faut -d (ou -a, qui l'inclut) :

cp -d lien.txt copie.txt
test -L copie.txt && echo "lien preserve"

Le même raisonnement vaut pour les sauvegardes : tar et rsync préservent les liens par défaut, mais cp -r seul les aplatit, ce qui peut multiplier par dix la taille d'une arborescence pleine de liens.

Sécurité : les protections du noyau

Les liens ont longtemps servi de vecteur d'attaque, en particulier dans les répertoires partagés comme /tmp. Le noyau Linux embarque deux protections, actives par défaut sur les distributions modernes.

sysctl fs.protected_hardlinks fs.protected_symlinks

fs.protected_hardlinks = 1
fs.protected_symlinks = 1

fs.protected_hardlinks interdit de créer un lien physique vers un fichier qu'on ne possède pas et pour lequel on n'a pas les droits d'écriture. Sans elle, un utilisateur pouvait créer un lien vers un fichier sensible, attendre qu'un processus privilégié en change les droits, et se retrouver avec un accès qu'il n'aurait jamais dû obtenir.

sudo -u autreuser ln /tmp/fichier-root /tmp/lien-vole

ln: failed to create hard link '/tmp/lien-vole' => '/tmp/fichier-root':
Operation not permitted

Inspecter les liens dans une arborescence

Quelques commandes d'inventaire, utiles lors d'un audit ou d'une migration.

# Tous les liens symboliques
find /opt -type l

# Uniquement les liens brisés
find /opt -xtype l

# Fichiers ayant plusieurs noms (liens physiques)
find /home -type f -links +1

# Parcourir en suivant les liens
find -L /opt -type f

Contrairement aux autres options de find, -L n'est pas un prédicat mais une option globale, et sa position compte :

find /opt -L -type f

find: unknown predicate `-L'

La forme correcte est find -L /opt -type f. Sur une arborescence contenant un lien vers un fichier, elle remonte bien deux entrées là où find /opt -type f n'en voit qu'une.

Dépannage

Un lien qui ne fait pas ce qu'on attend tombe presque toujours dans l'un de ces cas. Le tableau les classe par symptôme observable, puisque c'est ce dont vous disposez au moment du problème.

Symptôme	Cause probable	Solution
`No such file or directory` alors que `ls` affiche le lien	Lien brisé : la cible a disparu ou a été déplacée	`readlink -f <lien>` pour voir la destination, puis recréer le lien
Un lien créé fonctionne, puis casse après un déplacement	Le lien a été créé avec un chemin relatif	Le recréer en chemin absolu, ou déplacer les deux ensemble
`hard link not allowed for directory`	Lien physique vers un répertoire	Utiliser `ln -s`
`Invalid cross-device link`	Lien physique entre deux systèmes de fichiers	Utiliser `ln -s`
`Operation not permitted` sur un `ln`	`fs.protected_hardlinks` : vous ne possédez pas la cible	Passer par le propriétaire, ou utiliser un lien symbolique
`ln -sf` rend 0 mais le lien pointe toujours au même endroit	La cible est un répertoire, un lien a été créé dedans	Utiliser `ln -sfn`, et nettoyer le lien parasite créé
Le contenu d'un répertoire a disparu après un `rm`	`rm -r lien/` avec barre oblique finale	Restaurer depuis la sauvegarde ; ne jamais mettre de `/` final sur un lien
`chmod` sur un lien ne change rien	Les droits d'un lien ne sont jamais consultés sous Linux	Régler les droits de la cible ou du répertoire parent
Une copie pèse bien plus lourd que l'original	`cp -r` a suivi les liens et dupliqué les cibles	Utiliser `cp -a` (ou `-d`) pour préserver les liens

À retenir

Un fichier est un inode ; un nom n'est qu'une entrée de répertoire qui pointe vers lui.
Un lien physique est un nom de plus vers le même inode : même contenu, données conservées tant qu'un nom subsiste. Impossible vers un répertoire ou vers un autre système de fichiers.
Un lien symbolique contient un chemin. Il traverse les systèmes de fichiers, pointe vers des répertoires, et devient brisé si la cible disparaît.
ls -li tranche en une commande : inode identique pour un lien physique, type l et flèche pour un lien symbolique.
rm -r lien/ avec une barre oblique finale vide le répertoire cible en affichant Not a directory. Les trois autres formes sont sans danger.
Pour rediriger un lien, écrivez ln -sfn : sans -n, un lien vers un répertoire n'est pas remplacé mais dupliqué à l'intérieur.
chmod sur un lien ne sert à rien sous Linux, et cp sans -d copie la cible au lieu du lien.
fs.protected_hardlinks et fs.protected_symlinks sont des protections à conserver, même si leurs messages d'erreur ne les nomment pas.

Pour aller plus loin

Rechercher des fichiers : find en détail, pour inventorier les liens d'une arborescence.
Modifier les droits : les permissions qui comptent vraiment quand un lien est en jeu.
Archiver et compresser : comment tar traite les liens lors d'une sauvegarde.