Le FHS sous Linux : comprendre l’arborescence et savoir où ranger ses fichiers

Dans un système Linux, trouver un fichier n’est généralement pas difficile une fois que l’on comprend une idée essentielle :

les répertoires ne sont pas placés au hasard ; leur emplacement exprime souvent leur fonction.

Une configuration système va plutôt sous /etc.

Un journal sous /var/log.

Les données personnelles d’un utilisateur sous /home.

Une donnée temporaire sous /tmp.

Une bibliothèque fournie par la distribution sous /usr/lib.

Et le script bricolé à 2 h 14 du matin « juste pour dépanner » n’a normalement aucune raison de finir directement dans /usr/bin entre deux fichiers appartenant au gestionnaire de paquets.

Cette organisation est notamment décrite par le FHS — Filesystem Hierarchy Standard.

On peut le voir comme le plan de rangement d’un grand appartement Unix :

tout le monde peut posséder ses habitudes, mais lorsque la chaudière se trouve normalement dans la cave, la cacher derrière le canapé n’améliore pas vraiment la maintenance.

Qu’est-ce que le FHS ?

Le Filesystem Hierarchy Standard définit des règles et recommandations concernant l’emplacement des fichiers et répertoires sur les systèmes de type Unix.

Son objectif principal est de rendre l’organisation des systèmes suffisamment prévisible pour faciliter :

• l’interopérabilité des logiciels ;
• l’administration système ;
• la création de paquets ;
• l’écriture de scripts ;
• la documentation ;
• et, accessoirement, la santé mentale de la personne appelée à maintenir la machine trois ans plus tard.

Le FHS décrit notamment des emplacements comme :

/etc
/home
/usr
/var
/tmp
/run
/srv
/opt

avec une fonction générale associée à chacun.

Le FHS n’est pas une loi physique

Il serait cependant faux d’imaginer :

« Tout système Linux doit reproduire exactement le FHS sous peine d’explosion immédiate. »

Le FHS fournit un cadre commun.

Les distributions peuvent :

• ajouter des répertoires ;
• utiliser des liens symboliques ;
• faire évoluer certains choix historiques ;
• adopter des mécanismes plus modernes.

Debian moderne en fournit justement un excellent exemple avec le merged-/usr, que nous verrons plus loin.

Tout commence à la racine : /

L’arborescence Unix commence à :

/

appelé :

la racine
root directory

On peut représenter très grossièrement un système ainsi :

/
├── boot
├── dev
├── etc
├── home
├── media
├── mnt
├── opt
├── proc
├── root
├── run
├── srv
├── sys
├── tmp
├── usr
└── var

Tout ce qui est accessible dans l’espace de fichiers du système apparaît quelque part sous cette racine.

/ n’est pas exactement le C: de Linux

L’analogie :

« /, c’est le C: de Linux. »

peut aider pendant trente secondes, mais elle devient rapidement trompeuse.

Sous Windows, plusieurs volumes apparaissent traditionnellement comme :

C:
D:
E:

Dans le modèle Unix, différents systèmes de fichiers viennent généralement se monter dans une seule arborescence.

Par exemple :

/
├── home
├── srv
│   └── data
└── mnt
    └── backup

pourrait en réalité correspondre à :

• un SSD pour / ;
• un autre volume pour /home ;
• un RAID pour /srv/data ;
• un NAS monté sous /mnt/backup.

Pour les applications, tout cela forme néanmoins une arborescence continue.

Fichier, répertoire et autres créatures

On réduit souvent le système de fichiers à deux catégories :

• les fichiers ;
• les répertoires.

En réalité, Linux connaît plusieurs types d’objets.

Type	Exemple / usage
Fichier régulier	Document, programme, configuration
Répertoire	Contient des entrées vers d’autres objets
Lien symbolique	Pointe vers un autre chemin
Périphérique bloc	Disque ou volume sous /dev
Périphérique caractère	Terminal, périphérique séquentiel, etc.
Socket Unix	Communication entre processus
FIFO	Tube nommé

On entend souvent :

« Sous Unix, tout est fichier. »

L’idée est utile : de nombreuses ressources peuvent être manipulées à travers des interfaces proches de celles des fichiers.

Mais cela ne signifie pas qu’un disque, une socket et un fichier texte sont réellement le même objet.

Linux aime l’uniformité.

Il n’est pas pour autant atteint d’une incapacité totale à distinguer un SSD d’un fichier README.

Identifier le type d’un objet

La commande :

file /chemin/objet

permet d’obtenir des informations sur sa nature.

Par exemple :

file /bin/bash

ou :

file document.pdf

Pour obtenir davantage de métadonnées :

stat fichier

Les chemins absolus

Un chemin absolu commence à la racine :

/

Par exemple :

/etc/passwd
/home/alice/Documents/rapport.txt
/var/log/syslog

Quel que soit votre répertoire courant, le chemin :

/etc/passwd

désigne toujours le même emplacement dans cet espace de noms.

Les chemins relatifs

Un chemin relatif est interprété depuis le répertoire courant.

Supposons que vous soyez dans :

/home/alice

et que vous utilisiez :

Documents/rapport.txt

Le système comprend :

/home/alice/Documents/rapport.txt

dans ce contexte.

Le répertoire courant : .

Le symbole :

.

désigne le répertoire courant.

Ainsi :

./script.sh

signifie :

« le fichier script.sh situé dans le répertoire où je me trouve actuellement ».

Cela explique notamment pourquoi on lance souvent un programme local avec :

./programme

si son répertoire n’est pas présent dans la variable PATH.

Le répertoire parent : ..

Le symbole :

..

désigne le répertoire parent.

Si vous êtes dans :

/home/alice

alors :

..

désigne :

/home

et :

../bob

désigne :

/home/bob

sous réserve, évidemment, que ce répertoire existe et que vos permissions vous permettent d’y entrer.

Le tilde : ~

Dans de nombreux shells :

~

représente le répertoire personnel de l’utilisateur courant.

Pour Alice :

~/Documents

correspond typiquement à :

/home/alice/Documents

On peut également rencontrer :

~bob

pour désigner le répertoire personnel de Bob si le shell peut résoudre cette identité.

pwd : savoir où l’on se trouve

Avant certaines opérations, une commande mérite presque le statut de réflexe :

pwd

pour :

print working directory

Elle affiche le répertoire courant.

Exemple :

$ pwd
/home/alice/Documents

Avant une suppression récursive, savoir si vous êtes dans :

/home/alice/test

ou dans :

/etc

constitue une nuance administrativement intéressante.

ls : regarder autour de soi

La commande :

ls

affiche les entrées d’un répertoire.

Une variante classique :

ls -l

ajoute notamment :

• le type ;
• les permissions ;
• le propriétaire ;
• le groupe ;
• la taille ;
• la date de modification.

Pour inclure les fichiers cachés :

ls -la

Les fichiers cachés

Sous Unix, un fichier dont le nom commence par :

.

est conventionnellement caché dans les affichages ordinaires.

Par exemple :

.bashrc
.profile
.ssh
.config

Il n’existe pas un mystérieux attribut « invisible » ressemblant nécessairement à celui de Windows.

Le fichier commence simplement par un point.

Une solution de confidentialité qui repose essentiellement sur :

« Ne le montre pas sauf si je le demande. »

Ce n’est évidemment pas une mesure de sécurité.

Vue générale des principaux répertoires

Répertoire	Fonction principale
/	Racine de l’arborescence
/etc	Configuration système spécifique à la machine
/home	Répertoires personnels des utilisateurs
/root	Répertoire personnel de root
/usr	Grande hiérarchie contenant programmes, bibliothèques et données distribuées
/usr/local	Logiciels et données installés localement par l’administrateur
/var	Données variables du système
/run	Données volatiles nécessaires pendant l’exécution
/tmp	Fichiers temporaires
/var/tmp	Temporaires destinés à survivre plus longtemps
/boot	Fichiers nécessaires au démarrage
/dev	Nœuds représentant notamment les périphériques
/proc	Informations virtuelles sur processus et noyau
/sys	Informations et interfaces relatives au noyau et aux périphériques
/mnt	Montages temporaires administratifs
/media	Points de montage pour supports amovibles
/srv	Données servies par cette machine
/opt	Applications additionnelles

/etc : la configuration de la machine

/etc contient principalement la configuration spécifique au système.

On y rencontre par exemple :

/etc/hostname
/etc/hosts
/etc/fstab
/etc/passwd
/etc/ssh/
/etc/samba/
/etc/systemd/

Le principe général est :

/etc contient de la configuration, pas les données normales produites par les applications.

Une base de données de 300 Gio n’a donc normalement rien à faire dans :

/etc/postgresql/

sous prétexte que PostgreSQL possède effectivement des fichiers de configuration dans cette hiérarchie.

/etc/passwd ne contient normalement plus les mots de passe

Le nom :

/etc/passwd

peut induire en erreur.

Sur un Linux moderne utilisant le système classique de comptes locaux, les empreintes de mots de passe sont normalement stockées dans le fichier système Linux shadow, situé dans le répertoire /etc, avec des permissions beaucoup plus restrictives.

/etc/passwd contient essentiellement des informations publiques nécessaires à la résolution des utilisateurs :

• nom du compte ;
• UID ;
• GID principal ;
• répertoire personnel ;
• shell ;
• et quelques champs historiques.

/home : les données personnelles des utilisateurs

/home accueille généralement les répertoires personnels des utilisateurs ordinaires.

Par exemple :

/home/alice
/home/bob
/home/charles

On y trouve :

• documents ;
• téléchargements ;
• préférences utilisateur ;
• fichiers de configuration personnels ;
• données propres aux applications.

Le répertoire personnel est également disponible via la variable :

$HOME

Par exemple :

echo "$HOME"

Les configurations utilisateur

Une partie des configurations personnelles est traditionnellement stockée dans des fichiers cachés directement sous le home :

~/.bashrc
~/.profile
~/.vimrc

De nombreuses applications modernes utilisent aussi des emplacements comme :

~/.config
~/.local/share
~/.cache

Ces conventions utilisateur modernes ne se résument donc pas simplement à :

« Tout va directement dans /home/alice. »

Même la chambre de l’utilisateur possède désormais des placards.

/root : le home de root

L’utilisateur :

root

possède traditionnellement son répertoire personnel à :

/root

et non :

/home/root

Cela permet notamment de maintenir son home dans le système de fichiers racine indépendamment de la disponibilité éventuelle de /home.

Il faut distinguer :

/

la racine du système de fichiers, et :

/root

le répertoire personnel de l’utilisateur root.

Une seule syllabe de différence.

Quelques années d’administration système pour cesser de les confondre oralement.

/usr : beaucoup plus important que son nom ne le laisse penser

/usr constitue l’une des grandes hiérarchies du système.

On y trouve notamment :

/usr/bin
/usr/sbin
/usr/lib
/usr/share
/usr/include
/usr/local

Le nom usr a une histoire ancienne, mais il ne faut pas interpréter le répertoire moderne comme :

« les fichiers des utilisateurs ».

Les fichiers personnels sont normalement dans :

/home

/usr contient plutôt une grande partie des programmes et ressources fournies par le système.

/usr/bin : la majorité des commandes

On trouve sous :

/usr/bin

une très grande quantité de programmes accessibles aux utilisateurs.

Par exemple selon l’installation :

/usr/bin/python3
/usr/bin/grep
/usr/bin/find
/usr/bin/ssh

Pour découvrir la commande réellement utilisée :

command -v ssh

ou :

type ssh

/usr/sbin : outils système

/usr/sbin contient historiquement des programmes destinés principalement à l’administration système.

Point important :

sbin ne signifie pas « exécutables techniquement réservés à root ».

Un utilisateur ordinaire peut souvent exécuter le programme lui-même.

Il échouera simplement lorsqu’une opération exige réellement des privilèges.

Par exemple, consulter l’aide d’un outil d’administration ne nécessite pas nécessairement de devenir root.

Ce sont :

• les permissions ;
• les capacités ;
• les contrôles du noyau ;
• et les opérations effectuées ;

qui déterminent réellement ce qu’un utilisateur peut faire.

/bin et /sbin : attention aux anciens schémas

Historiquement :

/bin

contenait les commandes essentielles nécessaires même dans un environnement minimal, tandis que :

/sbin

contenait des exécutables système essentiels.

Cette distinction apparaît encore dans le FHS et dans énormément de documentation.

Mais sur Debian moderne, la situation physique est différente.

merged-/usr sur Debian moderne

Debian utilise désormais une organisation appelée :

merged-/usr

Dans cette architecture :

/bin  → /usr/bin
/sbin → /usr/sbin
/lib  → /usr/lib

et selon l’architecture :

/lib64 → /usr/lib64

sont des liens symboliques.

Vérifiez avec :

ls -ld /bin /sbin /lib

Vous pourrez obtenir quelque chose de conceptuellement similaire à :

/bin  -> usr/bin
/sbin -> usr/sbin
/lib  -> usr/lib

/bin/bash et /usr/bin/bash

Sur ce type de système :

/bin/bash

et :

/usr/bin/bash

finissent donc par atteindre le même programme.

Vous pouvez le constater avec :

readlink -f /bin/bash

La distinction historique reste importante pour comprendre :

• le FHS ;
• les scripts plus anciens ;
• les systèmes non fusionnés ;
• les raisons pour lesquelles certains chemins existent encore.

Mais il ne faut plus enseigner qu’un Debian moderne stocke réellement deux collections indépendantes d’exécutables dans /bin et /usr/bin.

Ne réorganisez pas merged-/usr à la main

Si vous découvrez ces liens :

/bin -> usr/bin

ne les remplacez pas par de vrais répertoires parce qu’un vieux tutoriel affirme que « Linux doit avoir un /bin séparé ».

Cette organisation est intentionnelle.

Transformer manuellement l’arborescence fondamentale de votre distribution constitue une excellente manière de convertir un cours sur le FHS en atelier de récupération système.

/usr/lib : bibliothèques et données internes aux paquets

/usr/lib accueille notamment :

• des bibliothèques ;
• des composants dépendants de l’architecture ;
• des données internes utilisées par des logiciels ;
• des sous-répertoires propres à certains paquets.

Sur les systèmes multiarchitecture comme Debian, vous pouvez également rencontrer des chemins plus précis, par exemple :

/usr/lib/x86_64-linux-gnu

selon l’architecture.

/usr/share : données indépendantes de l’architecture

/usr/share contient des données qui ne sont normalement pas spécifiques au processeur.

Par exemple :

/usr/share/man
/usr/share/doc
/usr/share/icons
/usr/share/zoneinfo

Vous y trouverez notamment :

• documentation ;
• pages de manuel ;
• icônes ;
• données linguistiques ;
• ressources diverses utilisées par les logiciels.

/usr/local : le territoire de l’administrateur

/usr/local est particulièrement important.

Il est destiné aux logiciels et fichiers installés localement par l’administrateur, en dehors de ce que fournit normalement la distribution.

Par exemple :

/usr/local/bin
/usr/local/sbin
/usr/local/lib
/usr/local/share

Si vous écrivez un script destiné à être disponible globalement :

/usr/local/bin/backup-local

est généralement beaucoup plus approprié que :

/usr/bin/backup-local

Pourquoi ne pas mettre mes scripts dans /usr/bin ?

Parce que :

/usr/bin

est normalement géré par les paquets de la distribution.

Y déposer manuellement vos fichiers crée plusieurs problèmes :

• conflits potentiels avec les paquets ;
• origine des fichiers moins claire ;
• maintenance plus difficile ;
• risque qu’un paquet utilise un jour le même nom.

La séparation est très utile :

/usr
→ distribution

/usr/local
→ administrateur local

Le jour où l’on se demande :

« Mais qui a installé ce binaire ? »

cette distinction commence à avoir une valeur presque sentimentale.

/var : tout ce qui varie

/var contient des données qui changent pendant le fonctionnement normal du système.

On y rencontre notamment :

/var/log
/var/lib
/var/cache
/var/spool
/var/tmp

Le nom vient de :

variable

et non de :

« endroit où mettre tout ce que je n’ai pas réussi à classer ailleurs ».

/var/log : les journaux

Le répertoire :

/var/log

contient traditionnellement les journaux du système et des services.

On peut y rencontrer selon les logiciels installés :

/var/log/auth.log
/var/log/apache2/
/var/log/nginx/
/var/log/apt/

Avec systemd, une partie importante de la journalisation peut aussi être gérée par :

systemd-journald

et consultée avec :

journalctl

Les journaux persistants de journald peuvent notamment résider sous :

/var/log/journal

selon la configuration.

/var/lib : l’état persistant des applications

/var/lib est extrêmement important pour les services.

Il contient des données d’état variables persistantes.

Par exemple :

/var/lib/dpkg
/var/lib/systemd
/var/lib/samba

et différents logiciels y placent :

• bases internes ;
• états ;
• métadonnées ;
• informations nécessaires entre deux démarrages.

Supprimer :

/var/lib/quelque-chose

parce que :

« var, c’est juste du temporaire »

constitue donc une très mauvaise interprétation du nom du répertoire.

/var/cache : données reconstructibles

/var/cache est destiné aux caches applicatifs.

L’idée générale est que les données présentes ici peuvent être recréées si elles disparaissent.

Par exemple, APT utilise :

/var/cache/apt

pour certaines de ses données de cache.

Un cache peut être précieux pour les performances.

Mais il ne devrait pas représenter l’unique exemplaire irremplaçable de vos données.

Sinon ce n’est plus vraiment un cache.

C’est une sauvegarde qui traverse une crise d’identité.

/var/spool : travail en attente

/var/spool accueille des données en attente de traitement.

Historiquement :

• files d’impression ;
• courrier ;
• tâches planifiées ;
• autres files d’attente.

Le mot important est :

spool

Une donnée arrive, attend son tour, puis est traitée par un service.

/var/tmp : temporaire, mais plus durable

/var/tmp est destiné aux fichiers temporaires qui doivent pouvoir survivre à un redémarrage.

C’est une différence fondamentale avec l’usage traditionnel de :

/tmp

Mais :

« survit au redémarrage » ne signifie pas « conservé pour toujours ».

Des mécanismes de nettoyage périodique peuvent supprimer les anciens fichiers.

/tmp : le vrai temporaire

/tmp est destiné aux fichiers temporaires.

Il ne faut jamais y stocker quelque chose en supposant :

« Je le récupérerai dans trois mois. »

Le contenu peut être supprimé :

• au redémarrage ;
• par une politique de nettoyage ;
• par l’administrateur ;
• ou lorsqu’un mécanisme spécifique de la distribution le prévoit.

/tmp sur Debian 13

Sur une nouvelle installation de Debian 13, /tmp utilise par défaut un :

tmpfs

c’est-à-dire un système de fichiers temporaire s’appuyant sur la mémoire virtuelle.

Son contenu disparaît donc lors du redémarrage.

Debian prévoit également, sur les nouvelles installations, un nettoyage périodique des anciens fichiers :

/tmp     : environ 10 jours d'inactivité
/var/tmp : environ 30 jours

La politique exacte peut être modifiée par l’administrateur, et un système ayant été mis à niveau depuis une version précédente peut conserver un comportement différent.

La règle correcte est donc : ne faites aucune hypothèse de conservation à long terme dans /tmp.

Le nom du répertoire avait pourtant tenté de vous prévenir.

Le sticky bit de /tmp

Un répertoire partagé comme /tmp possède généralement des permissions ressemblant à :

drwxrwxrwt

ou numériquement :

1777

Le :

t

représente le sticky bit.

Il permet à plusieurs utilisateurs d’écrire dans le répertoire tout en empêchant normalement un utilisateur ordinaire de supprimer arbitrairement les fichiers appartenant aux autres.

Sans ce mécanisme, /tmp serait moins un espace temporaire partagé qu’une expérience permanente de confiance entre inconnus.

/run : données de fonctionnement depuis le démarrage

/run accueille les données nécessaires pendant l’exécution du système et qui ne doivent pas persister après le redémarrage.

On peut y trouver :

• PID files ;
• sockets Unix ;
• états temporaires des services ;
• informations de session ;
• données créées très tôt pendant le boot.

Exemples possibles :

/run/systemd/
/run/user/
/run/lock/

/run est normalement un système de fichiers volatile.

/var/run et /run

Dans de nombreux systèmes modernes :

/var/run

est simplement un lien vers :

/run

Vous pouvez vérifier :

ls -ld /var/run

La transition permet de préserver d’anciens chemins tout en utilisant une hiérarchie runtime disponible très tôt pendant le démarrage.

/boot : le démarrage du système

/boot contient des fichiers nécessaires au démarrage.

On peut notamment y rencontrer :

vmlinuz-...
initrd.img-...
config-...
System.map-...
grub/

Le noyau Linux installé peut être représenté par des fichiers :

vmlinuz-6.x...

et l’initramfs par :

initrd.img-6.x...

Le chargeur de démarrage possède également ses propres fichiers.

/boot/efi

Sur une machine démarrant en UEFI, la partition système EFI peut être montée par exemple sous :

/boot/efi

selon l’installation.

Elle contient notamment des exécutables EFI et données utilisées pour le démarrage.

Ce n’est pas un répertoire à utiliser comme :

/boot/efi/anciens-fichiers-a-trier

simplement parce qu’il restait quelques centaines de mégaoctets libres.

/dev : les périphériques et fichiers spéciaux

/dev contient des nœuds représentant notamment des périphériques.

Exemples :

/dev/sda
/dev/sda1
/dev/nvme0n1
/dev/tty
/dev/null
/dev/zero
/dev/random

Un disque peut donc être représenté par :

/dev/sda

et une de ses partitions par :

/dev/sda1

Sur un SSD NVMe, vous rencontrerez plutôt quelque chose comme :

/dev/nvme0n1
/dev/nvme0n1p1

/dev n’est pas rempli de fichiers ordinaires

Faire :

ls -l /dev/null

ne montre pas un simple fichier texte vide.

/dev/null est un périphérique caractère.

Tout ce qu’on lui écrit est jeté.

Il s’agit probablement du système de classement le plus honnête de toute l’informatique.

devtmpfs et udev

Sur Linux moderne, le contenu de /dev est largement créé dynamiquement.

Le noyau expose des périphériques et des mécanismes comme :

devtmpfs
udev

participent à la création et à la gestion des nœuds et liens utiles.

/dev n’est donc pas simplement un dossier rempli une fois pour toutes lors de l’installation.

/proc : une fenêtre virtuelle sur le noyau

/proc est un pseudo-système de fichiers.

Son contenu n’est pas stocké sur votre SSD comme un ensemble de fichiers ordinaires.

Il expose dynamiquement des informations du noyau.

Par exemple :

/proc/cpuinfo
/proc/meminfo
/proc/mounts
/proc/uptime

Les processus sous /proc

Chaque processus possède également un répertoire correspondant à son PID.

Pour un processus :

PID 1234

on peut trouver :

/proc/1234/

avec des informations comme :

/proc/1234/cmdline
/proc/1234/status
/proc/1234/fd/

Pour votre shell courant :

echo $$

puis :

ls /proc/$$

permet d’explorer les informations que le noyau expose sur ce processus.

/proc n’est pas en lecture seule

Une autre simplification fréquente consiste à présenter /proc comme un simple tableau d’informations.

Certaines interfaces peuvent également être utilisées pour modifier des paramètres du noyau.

Par exemple, de nombreuses valeurs sous :

/proc/sys/

sont reliées aux paramètres accessibles via :

sysctl

Il vaut donc mieux considérer :

/proc/sys

comme une interface active avec le noyau et non comme un musée où toutes les vitrines sont verrouillées.

/sys : le modèle des périphériques et du noyau

/sys est également un pseudo-système de fichiers.

Il expose notamment le modèle des périphériques, bus, classes et paramètres du noyau.

Par exemple :

/sys/class/net
/sys/block
/sys/bus
/sys/devices

Pour voir les interfaces réseau :

ls /sys/class/net

Vous pourriez obtenir :

enp1s0
lo
wlan0

Comme dans /proc, certaines entrées peuvent aussi servir d’interface de contrôle lorsqu’elles sont modifiables.

/mnt : montages temporaires administratifs

/mnt est traditionnellement prévu comme point de montage temporaire.

Par exemple :

sudo mkdir -p /mnt/test
sudo mount /dev/sdb1 /mnt/test

Il est particulièrement pratique lorsqu’un administrateur veut :

• examiner un disque ;
• tester un système de fichiers ;
• effectuer une récupération ;
• monter temporairement une ressource.

/mnt est donc davantage l’établi du technicien que le salon destiné à rester organisé pendant dix ans.

/media : supports amovibles

/media est destiné aux points de montage des supports amovibles.

Sur un environnement de bureau, vous pouvez rencontrer quelque chose comme :

/media/alice/CLE-USB

lorsque l’environnement graphique monte automatiquement une clé USB.

La structure exacte dépend néanmoins des outils utilisés.

Le FHS indique la destination générale.

Il ne promet pas que tous les bureaux Linux nommeront votre clé USB de la même manière.

/mnt et /media : quelle différence ?

Répertoire	Usage typique
/mnt	Montage temporaire choisi par l’administrateur
/media	Supports amovibles, souvent montés automatiquement

Ce ne sont pas des règles cryptographiques.

Vous pourriez techniquement monter votre NAS sous :

/home/alice/patate

Linux ne convoquerait pas immédiatement la police du FHS.

Mais quelqu’un devra ensuite maintenir cette décision.

Et cette personne pourrait être vous.

/srv : données servies par la machine

/srv est destiné aux données correspondant aux services fournis par le système.

Par exemple :

/srv/www
/srv/ftp
/srv/samba
/srv/backups

selon la politique locale.

Un serveur Samba pourrait par exemple utiliser :

/srv/samba/documents

Un serveur web pourrait utiliser :

/srv/www/site

L’idée est de rendre claire la distinction entre :

les données du service

et :

le logiciel qui fournit le service

/srv et /var/lib : quelle différence ?

La frontière peut sembler floue.

Une règle mentale utile :

Répertoire	Idée générale
/srv	Données que la machine fournit directement comme service
/var/lib	État persistant interne d’une application

Par exemple :

/srv/samba/documents

peut contenir les documents proposés aux utilisateurs, tandis que :

/var/lib/samba

contient l’état interne nécessaire à Samba.

Les deux appartiennent au serveur.

Mais supprimer l’un vous fait perdre des documents ; supprimer l’autre peut transformer Samba en sujet du prochain ticket d’incident.

/opt : logiciels additionnels

/opt est prévu pour des logiciels additionnels, souvent distribués sous forme relativement autonome.

Par exemple :

/opt/mon-logiciel/
/opt/vendor/application/

Une application tierce peut y conserver :

• ses exécutables ;
• ses bibliothèques ;
• ses ressources propres.

On rencontre souvent /opt pour des logiciels propriétaires ou installés indépendamment de l’organisation habituelle des paquets de la distribution.

/opt ou /usr/local ?

Une règle pratique :

• /usr/local reproduit la hiérarchie Unix classique pour les logiciels administrés localement ;
• /opt convient bien à une application autonome regroupée sous son propre répertoire.

Par exemple :

/usr/local/bin/outil-maison

pour un script local simple.

Et :

/opt/superlogiciel/

pour une suite applicative installée comme un ensemble indépendant.

/lib : les bibliothèques essentielles, historiquement

Le FHS historique prévoit :

/lib

pour certaines bibliothèques essentielles nécessaires aux programmes de /bin et /sbin.

Sur Debian utilisant merged-/usr :

/lib

est normalement redirigé vers :

/usr/lib

La distinction historique reste utile pour comprendre les chemins rencontrés dans la documentation, mais il faut tenir compte de la structure réelle de la distribution.

Où placer quoi ?

Voici un résumé particulièrement utile pour un administrateur.

Ce que vous voulez stocker	Emplacement typique
Configuration système locale	/etc
Documents d’un utilisateur	/home/utilisateur
Script installé localement pour tous	/usr/local/bin
Outil d’administration local	/usr/local/sbin
Application tierce autonome	/opt/application
Données servies par la machine	/srv
État interne persistant d’un service	/var/lib
Cache reconstructible	/var/cache
Journaux	/var/log
Données runtime volatiles	/run
Temporaire court	/tmp
Temporaire devant survivre au reboot	/var/tmp

Les liens symboliques

Un lien symbolique est une entrée contenant une référence vers un autre chemin.

On peut en créer un avec :

ln -s cible lien

Par exemple :

ln -s /srv/documents ~/documents-partages

Le lien :

~/documents-partages

renvoie alors vers :

/srv/documents

Examiner un lien symbolique

Avec :

ls -l lien

vous verrez quelque chose comme :

documents-partages -> /srv/documents

Pour connaître la cible finale :

readlink -f lien

Cette commande est particulièrement utile sur Debian moderne pour comprendre ce que deviennent :

/bin
/sbin
/lib

Les liens durs

Un hard link fonctionne différemment.

Deux noms peuvent référencer le même inode dans le même système de fichiers.

Par exemple :

ln fichier original-bis

Les deux noms pointent alors vers le même contenu sous-jacent.

Contrairement au lien symbolique :

• le hard link ne stocke pas simplement un chemin cible ;
• il ne traverse normalement pas les systèmes de fichiers ;
• les restrictions concernant les répertoires sont différentes.

Ce sujet dépasse le FHS lui-même, mais il explique pourquoi :

« Un fichier se trouve à cet endroit. »

n’est pas toujours une description aussi simple qu’elle en a l’air.

Les points de montage rendent l’arborescence trompeusement homogène

Exécutez :

findmnt

et vous découvrirez que l’arborescence visible rassemble potentiellement de nombreux systèmes de fichiers.

Par exemple :

/
├── /boot
├── /home
├── /proc
├── /sys
├── /dev
├── /run
└── /tmp

peuvent être associés à des systèmes de fichiers très différents.

Pour l’utilisateur :

ce sont des répertoires.

Pour le noyau :

c’est un assemblage soigneusement monté de plusieurs mondes qui essaient de donner l’impression d’habiter le même immeuble.

Voir les systèmes de fichiers montés

Utilisez :

findmnt

ou :

df -hT

findmnt est particulièrement pratique pour comprendre :

• la source ;
• la cible ;
• le type de système de fichiers ;
• les options de montage.

df et du ne répondent pas à la même question

Pour voir l’espace d’un système de fichiers :

df -h

Pour mesurer l’espace occupé par un répertoire :

du -sh /var/log

Par exemple :

sudo du -sh /var/*

peut aider à découvrir pourquoi :

/var

vient de remplir le disque.

Et pourquoi, mystérieusement, les logs d’une application contiennent 240 Gio de la même erreur répétée toutes les 20 millisecondes depuis jeudi.

La variable PATH

Lorsque vous tapez :

ls

le shell ne fouille pas l’intégralité du disque dans l’espoir de trouver un programme portant ce nom.

Il consulte notamment la variable :

PATH

Pour l’afficher :

echo "$PATH"

Vous pourriez obtenir :

/usr/local/bin:/usr/bin:/bin

avec davantage d’entrées selon votre système.

Pour connaître le programme sélectionné :

command -v ls

Pourquoi ./script.sh ?

Le répertoire courant :

.

n’est généralement pas ajouté automatiquement au PATH.

Si votre script est ici :

./script.sh

vous indiquez explicitement :

« Exécute le fichier appelé script.sh situé ici. »

Cela évite notamment qu’un fichier malveillant nommé :

ls

déposé dans un répertoire quelconque soit automatiquement exécuté avant le véritable :

/usr/bin/ls

Inspecter l’arborescence sans deviner

Quelques commandes suffisent pour comprendre où vous êtes et ce que vous regardez.

Commande	Fonction
pwd	Afficher le répertoire courant
ls -la	Lister les fichiers, y compris cachés
file	Identifier la nature d’un fichier
stat	Afficher ses métadonnées
readlink -f	Résoudre un lien vers sa cible finale
findmnt	Afficher les systèmes de fichiers montés
df -hT	Voir espace disponible et type de système de fichiers
du -sh	Mesurer l’espace utilisé par un répertoire
command -v	Trouver la commande réellement appelée

Quelques emplacements à ne pas confondre

/etc et /var/lib

/etc/application
→ configuration choisie par l'administrateur

/var/lib/application
→ état persistant maintenu par l'application

/run et /var/lib

/run/application
→ état nécessaire pendant cette exécution

/var/lib/application
→ état qui doit survivre au redémarrage

/tmp et /var/tmp

/tmp
→ temporaire à durée courte

/var/tmp
→ temporaire pouvant devoir survivre au redémarrage

/usr et /usr/local

/usr
→ principalement géré par la distribution

/usr/local
→ administré localement

/mnt et /media

/mnt
→ montages temporaires administratifs

/media
→ supports amovibles

/srv et /var/lib

/srv
→ données que le service fournit

/var/lib
→ état interne du service

Le FHS et le gestionnaire de paquets

Sur Debian, une grande partie du contenu de :

/usr/bin
/usr/lib
/usr/share

provient des paquets installés avec :

apt
dpkg

Pour savoir quel paquet possède un fichier :

dpkg -S /usr/bin/ssh

Pour afficher tous les fichiers appartenant à un paquet :

dpkg -L openssh-client

C’est extrêmement utile pour répondre à :

« Ce fichier vient-il de Debian ou quelqu’un l’a-t-il ajouté manuellement ? »

Ne modifiez pas directement un fichier fourni par un paquet sans comprendre son rôle

Un fichier sous :

/usr/lib
/usr/share
/usr/bin

peut être remplacé lors d’une mise à jour.

Pour les configurations destinées à l’administrateur, les logiciels utilisent généralement des mécanismes spécifiques sous :

/etc

ou des systèmes de surcharge prévus pour cela.

Modifier directement :

/usr/lib/quelque-chose/fichier

et être surpris qu’APT écrase la modification six mois plus tard est une tradition que l’on peut parfaitement choisir de ne pas perpétuer.

Les fichiers de configuration modernes : /usr et /etc peuvent coopérer

Certains logiciels modernes utilisent une logique de configuration en plusieurs niveaux.

On peut par exemple avoir :

/usr/lib/...

pour les valeurs fournies par le logiciel ou la distribution, et :

/etc/...

pour les surcharges décidées par l’administrateur.

Le principe reste cohérent :

/usr contient ce que fournit le système ; /etc décrit ce que cette machine veut en faire.

La mise en œuvre précise dépend toutefois du logiciel.

/lost+found : pourquoi est-il parfois là ?

Sur certains systèmes de fichiers comme ext4, vous pouvez rencontrer :

lost+found

à la racine d’un système de fichiers.

Ce répertoire n’est pas un grand composant général du FHS.

Il appartient plutôt au fonctionnement de certains systèmes de fichiers et peut être utilisé par leurs outils de vérification pour récupérer des fragments ou objets retrouvés.

Il n’est donc pas recommandé de le transformer en :

/lost+found/photos-vacances

simplement parce que son nom vous paraissait approprié.

Les permissions traversent toute l’arborescence

Avoir le droit de lire :

/srv/secret/rapport.txt

ne suffit pas nécessairement.

Il faut aussi pouvoir traverser les répertoires parents.

La commande :

namei -l /srv/secret/rapport.txt

est très pratique pour examiner chaque composant du chemin.

Elle peut révéler par exemple :

/
srv
secret
rapport.txt

avec les permissions correspondantes.

Une permission correcte sur le fichier final ne compense pas un répertoire parent qui vous interdit de passer.

Le videur se trouve parfois trois portes avant la salle.

Attention aux suppressions récursives

Une commande comme :

rm -rf *

agit sur ce que votre shell développe à partir du répertoire courant.

La première question ne devrait donc pas être :

« Est-ce que rm va être rapide ? »

mais :

pwd

puis :

ls

et idéalement une vérification que la cible correspond réellement à votre intention.

La vitesse de rm est une qualité remarquable lorsque vous avez raison.

Elle l’est beaucoup moins lorsque vous avez tort.

Et les fichiers cachés avec * ?

Dans un shell classique, le glob :

*

ne correspond normalement pas aux noms commençant par un point.

Ainsi :

rm -rf *

et :

« supprimer absolument tout le contenu, fichiers cachés compris »

ne sont pas nécessairement la même chose.

Ce détail explique parfois pourquoi un répertoire paraît vide mais contient encore :

.config
.git
.env

Les fichiers cachés ne sont pas morts.

Ils ont seulement respecté leur contrat.

Lire le manuel avant de réorganiser Linux

Plusieurs commandes donnent directement accès à la documentation :

man hier

Sur de nombreux systèmes, cette page décrit l’organisation générale de l’arborescence.

On peut également utiliser :

man file-hierarchy

lorsque cette documentation est installée, notamment pour une vision liée aux systèmes modernes utilisant systemd.

Et évidemment :

man commande

reste souvent préférable à un tutoriel aléatoire expliquant que Linux exige encore une partition séparée de 50 Mio pour /bin parce que son auteur l’avait fait sur Slackware en 1998.

Exemple : où installer un script maison ?

Vous écrivez :

backup-database

et souhaitez que les administrateurs puissent l’utiliser.

Un emplacement cohérent est :

/usr/local/sbin/backup-database

ou :

/usr/local/bin/backup-database

selon son public et son rôle.

Vous évitez ainsi :

/usr/bin
/bin

qui appartiennent conceptuellement à la distribution.

Exemple : où placer une application tierce autonome ?

Vous installez une application fournie directement par un éditeur :

SuperGestion 5

Une organisation possible :

/opt/supergestion/
├── bin
├── lib
└── share

Puis éventuellement un lien pratique :

/usr/local/bin/supergestion

vers son exécutable principal.

Exemple : où stocker un partage Samba ?

Pour des documents servis par la machine :

/srv/samba/documents

est un emplacement cohérent.

La configuration Samba elle-même reste plutôt sous :

/etc/samba/

et son état interne peut se trouver sous :

/var/lib/samba/

On retrouve ainsi trois fonctions clairement séparées :

/etc/samba
→ configuration

/var/lib/samba
→ état interne

/srv/samba
→ données fournies aux clients

C’est exactement le genre d’organisation que le FHS cherche à rendre intuitive.

Exemple : où stocker un log personnalisé ?

Un service local pourrait écrire sous :

/var/log/monservice/

à condition que :

• les permissions soient adaptées ;
• la rotation des journaux soit gérée ;
• le service ne remplisse pas tranquillement tout le disque pendant les vacances de l’administrateur.

Pour la rotation, on rencontre notamment :

logrotate

ou les mécanismes propres au journal systemd selon la façon dont le service journalise.

Exemple : où stocker un PID ou une socket runtime ?

Pour une donnée qui n’a de sens que tant que le service fonctionne :

/run/monservice/

est conceptuellement beaucoup plus adapté que :

/var/lib/monservice/

Un PID de processus datant du démarrage précédent possède rarement une grande valeur sentimentale.

Exemple : où stocker une base applicative ?

Une donnée persistante interne à un service peut naturellement appartenir à :

/var/lib/monservice/

mais l’emplacement exact doit suivre la documentation de l’application ou le paquet Debian.

Ne déplacez pas arbitrairement les données de PostgreSQL, MariaDB ou autre service uniquement pour que l’arborescence « vous paraisse plus propre ».

Une architecture élégante est celle que les logiciels savent également retrouver au démarrage.

Résumé : le grand appartement Linux

Pièce	Ce qu’on y trouve
/	Le hall central de toute l’arborescence
/etc	Les réglages de la maison
/home	Les chambres des utilisateurs
/root	La chambre de l’administrateur suprême
/usr	Une grande partie des logiciels et ressources du système
/usr/local	Ce que l’administrateur installe lui-même
/var	Ce qui change et s’accumule pendant l’exploitation
/run	Les post-it nécessaires uniquement jusqu’au prochain démarrage
/tmp	La table où l’on pose quelque chose sans promettre de le retrouver demain
/var/tmp	Le temporaire un peu moins suicidaire
/boot	Ce qui permet d’ouvrir la maison
/dev	Les interfaces avec le matériel et périphériques spéciaux
/proc	Une fenêtre sur les processus et le noyau
/sys	Le tableau électrique du modèle périphériques/noyau
/mnt	L’établi des montages temporaires
/media	Le vestiaire des supports amovibles
/srv	Ce que la machine sert aux autres
/opt	Les extensions et applications additionnelles

Les répertoires à connaître absolument

Chemin	Rôle essentiel
/etc	Configuration système
/home	Données personnelles
/usr/bin	Commandes utilisateur
/usr/sbin	Commandes principalement administratives
/usr/local	Installations locales
/var/log	Journaux
/var/lib	État persistant
/var/cache	Cache reconstructible
/run	État runtime volatil
/tmp	Fichiers temporaires
/srv	Données de services
/opt	Applications additionnelles
/dev	Périphériques
/proc	Processus et noyau
/sys	Périphériques et interfaces du noyau

Les idées fausses à abandonner

« / est le C: de Linux »

Seulement comme analogie introductive.

Linux assemble normalement plusieurs systèmes de fichiers dans une unique arborescence.

« /sbin est réservé à root »

Non.

Il contient historiquement des programmes principalement liés à l’administration système.

Les permissions déterminent qui peut réellement effectuer les opérations privilégiées.

« /bin et /usr/bin sont forcément deux répertoires physiques »

Pas sur Debian moderne utilisant merged-/usr.

/bin est normalement un lien vers /usr/bin.

« /var contient du temporaire »

Non.

/var/lib peut contenir des données absolument essentielles et persistantes.

« /tmp est conservé jusqu’au prochain reboot »

Aucune garantie générale.

Il peut être nettoyé pendant l’exécution et, sur Debian 13 neuf, il est également volatil au redémarrage par défaut.

« Tout ce qui commence par un point est sécurisé »

Non.

C’est simplement caché par convention dans certains affichages.

« Tout est littéralement un fichier normal »

Non plus.

Linux fournit une interface très unifiée, mais distingue fichiers réguliers, répertoires, sockets, périphériques et autres objets.

Quelques réflexes avant de modifier le système

1. Vérifiez où vous êtes avec pwd.
2. Regardez ce que contient le répertoire avec ls -la.
3. Vérifiez s’il s’agit d’un montage avec findmnt.
4. Vérifiez les liens avec readlink -f.
5. Identifiez le propriétaire d’un fichier Debian avec dpkg -S.
6. Utilisez /usr/local ou /opt plutôt que de polluer les chemins gérés par les paquets.
7. Ne considérez jamais /tmp comme un espace de stockage durable.
8. Ne supprimez pas un répertoire sous /var/lib simplement pour « faire de la place ».

Conclusion : Linux n’est pas en désordre, il possède simplement beaucoup de placards

Le FHS ne sert pas à mémoriser une liste de vingt répertoires pour réussir un questionnaire.

Son véritable intérêt est de comprendre la logique de l’arborescence.

Lorsque vous voyez :

/etc/monservice

vous devez commencer à penser :

configuration

Lorsque vous voyez :

/var/lib/monservice

pensez :

état persistant

Lorsque vous voyez :

/var/log/monservice

pensez :

journaux

Et lorsque vous voyez :

/run/monservice

pensez :

données utiles pendant l'exécution actuelle

Cette logique est beaucoup plus importante que d’apprendre mécaniquement que /bin « contient les commandes essentielles », surtout maintenant qu’un Debian moderne vous répondra tranquillement :

/bin -> usr/bin

Le système de fichiers Linux ressemble finalement à un grand appartement bien organisé :

• les utilisateurs ont leurs chambres ;
• les configurations ont leurs classeurs ;
• les services possèdent leurs données ;
• les logs s’accumulent dans la cave ;
• les périphériques apparaissent dans un placard étrange appelé /dev ;
• et /tmp est cette table commune où personne ne garantit que votre tasse sera encore présente demain matin.

Le bon administrateur ne connaît pas nécessairement chaque fichier du système.
Il sait surtout dans quelle partie de l’arborescence il devrait commencer à chercher.

Et avant toute commande destructive, il connaît également une autre tradition Unix d’une efficacité remarquable :

pwd

Deux secondes de vérification.

Parfois plusieurs heures de restauration évitées.