Surveiller un disque USB sous Linux : le guide du pont qui ment

SMART, c’est merveilleux. Sauf quand on branche un disque en USB et qu’on se prend un laconique « Unknown USB bridge ». Pourquoi ? Parce qu’entre votre OS et le disque, il y a un petit traducteur fantasque qui parle parfois SMART, parfois pas, parfois mal. Voici comment dompter cette interface mal-aimée et garder un œil sur la santé de vos disques externes.

Pourquoi l’USB complique tout

Sur un disque SATA branché en interne, c’est simple : votre OS envoie des commandes SATA directement au disque, qui répond directement. SMART fait partie du jeu de commandes SATA standard, tout fonctionne.

Sur un disque USB, l’architecture change radicalement. Il y a maintenant trois acteurs :

1. Votre OS, qui parle USB Mass Storage (ou plus précisément UAS, USB Attached SCSI, depuis USB 3.0).
2. Le pont USB-SATA ou USB-NVMe, une petite puce contrôleur intégrée au boîtier ou au dock.
3. Le disque lui-même, qui ne parle que SATA ou NVMe.

Le pont est un traducteur : il reçoit du SCSI/UAS depuis l’OS et le retraduit en SATA ou NVMe vers le disque. Pour les opérations de base (lire un secteur, écrire un secteur), tout va bien : le standard USB Mass Storage couvre tout ça.

Le problème, c’est que SMART n’existe pas dans USB Mass Storage. Les commandes SMART sont des commandes ATA (ou NVMe Admin), totalement étrangères à USB. Pour les faire passer, le pont doit savoir les encapsuler dans une commande SCSI personnalisée, puis les désencapsuler côté disque. Cette opération s’appelle un tunnel ou un passthrough.

Et là, c’est la jungle. Certains ponts savent faire, d’autres pas. Ceux qui savent utilisent des protocoles différents. Et la norme officielle (SAT, SCSI-ATA Translation) n’est respectée que par une partie d’entre eux.

💡 Pour résumer : un disque USB n’expose pas directement SMART. Tout dépend de la générosité du pont USB qui s’interpose. Bonne nouvelle : la plupart des ponts récents (post-2015) le font correctement.

Identifier son pont USB

Avant de chercher à interroger SMART, il faut savoir à qui on s’adresse. Trois commandes essentielles :

lsusb : qui est branché ?

$ lsusb
Bus 002 Device 005: ID 152d:0578 JMicron Technology Corp. JMS567 SATA 6Gb/s bridge
Bus 002 Device 003: ID 174c:55aa ASMedia Technology Inc. ASM1051E SATA 6Gb/s bridge

L’identifiant 152d:0578 est ce qui compte : c’est la signature unique du pont (vendor:product). C’est cette information qu’il faut chercher sur le wiki de smartmontools pour savoir quel protocole utiliser.

Quel /dev/sdX correspond à quel pont ?

Quand plusieurs disques USB sont branchés, il faut faire le lien entre l’identifiant USB et le device Linux :

$ ls -la /dev/disk/by-id/
lrwxrwxrwx 1 root root  9 Mar 12 14:23 usb-JMicron_Generic_DISK01-0:0 -> ../../sdb
lrwxrwxrwx 1 root root  9 Mar 12 14:23 usb-ASMT_2115_AB12345-0:0 -> ../../sdc

Le préfixe usb- indique clairement qu’il s’agit d’un disque externe, et la fin du nom dévoile le constructeur du pont (JMicron, ASMT pour ASMedia, etc.).

dmesg pour la vérité technique

$ sudo dmesg | grep -i -E "usb-storage|uas|scsi" | tail -20
[12345.678] usb 2-1: new SuperSpeed Gen 1 USB device number 5 using xhci_hcd
[12345.712] usb 2-1: Product: USB to ATA/ATAPI Bridge
[12345.712] usb 2-1: Manufacturer: JMicron
[12346.001] scsi host6: uas
[12346.234] scsi 6:0:0:0: Direct-Access     JMicron  Generic          0204 PQ: 0 ANSI: 6
[12346.456] sd 6:0:0:0: [sdb] Attached SCSI disk

Ces logs vous disent :

• le pont est détecté (Manufacturer: JMicron)
• le protocole utilisé est UAS (et non BOT, l’ancien)
• le disque est attaché en tant que /dev/sdb

Faire parler SMART à travers le pont

La commande clé est l’option -d de smartctl, qui indique le type de tunneling à utiliser.

L’auto-détection (à essayer en premier)

Depuis smartmontools 7.0, l’auto-détection fonctionne pour la plupart des ponts modernes. Tentez simplement :

sudo smartctl -a /dev/sdb

Si vous voyez les attributs SMART s’afficher normalement, tout va bien, le reste de cet article ne vous concerne pas. Si vous obtenez :

/dev/sdb: Unknown USB bridge [0x152d:0x0578 (0x9001)]
Please specify device type with the -d option.

…alors il faut spécifier manuellement le protocole.

Les protocoles à essayer pour un disque SATA en boîtier USB

# SAT (SCSI-ATA Translation), le protocole standard, à essayer en premier
sudo smartctl -d sat -a /dev/sdb

# SAT avec commandes 12 octets au lieu de 16 (vieux ponts WD notamment)
sudo smartctl -d sat,12 -a /dev/sdb

# JMicron (très répandus dans les boîtiers bas/milieu de gamme)
sudo smartctl -d usbjmicron -a /dev/sdb

# Cypress (ponts un peu plus anciens)
sudo smartctl -d usbcypress -a /dev/sdb

# Sunplus
sudo smartctl -d usbsunplus -a /dev/sdb

# Prolific
sudo smartctl -d usbprolific -a /dev/sdb

Les protocoles pour un SSD NVMe en boîtier USB

Les boîtiers NVMe-USB sont devenus la norme pour les SSD externes haute performance. Trois ponts dominent le marché :

# JMicron JMS583 — le plus répandu
sudo smartctl -d sntjmicron -a /dev/sdb

# ASMedia ASM2362
sudo smartctl -d sntasmedia -a /dev/sdb

# Realtek RTL9210
sudo smartctl -d sntrealtek -a /dev/sdb

🎯 Méthode efficace : si vous ne savez pas, testez sntjmicron → sntasmedia → sntrealtek dans cet ordre. Ces trois ponts couvrent 90 % des boîtiers NVMe-USB du marché.

Cas particulier : nvme-cli en passthrough

Certains boîtiers NVMe-USB modernes exposent suffisamment d’API pour que nvme-cli fonctionne directement, sans passer par smartctl :

sudo nvme smart-log /dev/sdb

Si ça marche, vous obtenez exactement les mêmes informations qu’avec un NVMe interne, sans bidouille. Si ça ne marche pas, retombez sur smartctl -d snt*.

La référence : le wiki smartmontools

Le projet smartmontools maintient une liste exhaustive des ponts USB testés avec, pour chacun, l’option -d qui fonctionne. Si vous avez le vendor:product de lsusb, vous y trouverez probablement la réponse exacte.

Lire les résultats : ce qui change avec l’USB

Une fois que SMART répond, les indicateurs à surveiller sont exactement les mêmes que pour un disque interne. Pour mémoire, sur un HDD on regarde :

• 5 (Reallocated_Sector_Ct), 187 (Reported_Uncorrect), 188 (Command_Timeout), 197 (Current_Pending_Sector), 198 (Offline_Uncorrectable) — doivent rester à zéro.
• 194 (Temperature) — idéalement entre 25 et 45°C.
• 9 (Power_On_Hours) — pour le contexte.

Sur un SSD NVMe, on surveille :

• Percentage Used — l’usure consommée.
• Available Spare — la réserve restante.
• Media and Data Integrity Errors — doit être à zéro.
• Critical Warning — doit afficher 0x00.

Mais attention, l’USB ajoute des pièges spécifiques qui peuvent fausser ou rendre suspectes ces lectures. C’est tout l’objet de la section suivante.

Les pièges spécifiques à l’USB

Le pont qui ment

Certains ponts USB bas de gamme répondent aux requêtes SMART avec des données partielles, tronquées ou inventées. Vous pouvez voir :

• une température constante à 0°C ou 128°C (valeur sentinelle pour “non disponible”)
• un Power_On_Hours qui ne bouge jamais malgré des heures d’utilisation
• des attributs critiques affichant des valeurs aberrantes ou impossibles
• l’absence complète de certains attributs pourtant standards

Comment savoir si votre pont ment ? Le test ultime : sortez le disque du boîtier et testez-le en SATA direct (avec un adaptateur SATA ou en le branchant temporairement en interne). Si les chiffres diffèrent, c’est le pont qui est en cause. Le disque, lui, dit la vérité quand on l’interroge directement.

La mise en veille agressive

Les disques USB se mettent en veille beaucoup plus agressivement que les disques internes. C’est volontaire (économie d’énergie sur les boîtiers alimentés par USB), mais ça a deux conséquences :

Premièrement, chaque interrogation SMART risque de réveiller le disque. Sur un HDD, c’est de la mécanique sollicitée pour rien : à raison de plusieurs vérifications par jour, vous accumulez des cycles de démarrage (compteur Power_Cycle_Count) inutiles, ce qui réduit la durée de vie. Pour éviter ça :

# N'interroger que si le disque est déjà actif
sudo smartctl -n standby -a /dev/sdb

L’option -n standby dit à smartctl de retourner immédiatement sans réveiller le disque si celui-ci est en veille.

Deuxièmement, certains disques externes (notamment les WD Elements et Seagate Backup Plus) ont une veille tellement agressive qu’ils se déconnectent purement et simplement après quelques minutes d’inactivité. Pour des sauvegardes longues, c’est catastrophique. Une solution :

# Désactiver l'autosuspend USB pour un périphérique précis
# Identifier le path USB
ls /sys/bus/usb/devices/

# Désactiver
echo on | sudo tee /sys/bus/usb/devices/2-1/power/control

Cette commande désactive l’autosuspend pour le périphérique branché sur le port USB 2-1. Adaptez selon votre configuration.

UAS vs BOT : choisir son protocole de transport

Deux protocoles coexistent pour les disques USB :

• BOT (Bulk-Only Transport) : ancien, lent, mais ultra-compatible.
• UAS (USB Attached SCSI) : moderne, performant, supporte mieux SMART et les commandes avancées.

UAS est utilisé automatiquement par Linux quand il est disponible (USB 3.0+ avec un pont compatible). Le problème, c’est qu’un certain nombre de ponts ASMedia anciens annoncent UAS mais ne l’implémentent pas correctement. Résultat : déconnexions intempestives, erreurs I/O, performances aléatoires.

Si vous suspectez ce problème (vérifiez avec dmesg), vous pouvez forcer le passage en BOT pour un pont précis :

# Créer un fichier de quirks
sudo nano /etc/modprobe.d/usb-storage-quirks.conf

Avec le contenu :

options usb-storage quirks=152d:0578:u

Le :u à la fin force le mode BOT (le u signifie ignore UAS). L’identifiant 152d:0578 est celui obtenu via lsusb. Recharger le module ou redémarrer pour appliquer.

Les disques externes “tout-en-un” : WD My Passport, Seagate Backup Plus

Ces disques grand public sont des cas particuliers. Ils ont une PCB unique qui intègre le pont USB directement avec le contrôleur SATA du disque — pas de boîtier à ouvrir, pas de disque SATA standard à l’intérieur.

Spécificité 1 : beaucoup utilisent un chiffrement matériel transparent (l’AES est appliqué par le pont). Si vous sortez le disque de son boîtier pour le brancher en SATA direct, il est illisible. C’est une protection contre le vol, mais c’est aussi un piège : si le pont tombe en panne, vos données sont perdues même si le disque va bien.

Spécificité 2 : certains modèles WD utilisent un protocole SMART non standard, nécessitant des options spécifiques :

# Pour les WD My Passport récents
sudo smartctl -d sat,16 -a /dev/sdb

# Pour les vieux modèles
sudo smartctl -d sat,12 -a /dev/sdb

Spécificité 3 : la température reportée est souvent celle du pont, pas du disque. Méfiez-vous des valeurs très élevées (50-60°C) sur un disque externe au repos : ça peut être normal, le pont chauffant nettement plus que la mécanique.

Les hubs USB et les docks multi-baies

Si vos disques passent par un hub USB ou un dock multi-baies (type “station d’accueil 4 disques”), une couche supplémentaire s’ajoute. La plupart des docks corrects font passer SMART correctement, mais certains hubs introduisent des limitations :

• bande passante partagée → ralentissements lors de tests intensifs
• alimentation insuffisante → veille spontanée des disques sous charge
• timeout SMART → réponses tronquées sur des disques pourtant sains

En cas de doute, branchez le disque suspect en direct sur la carte mère pour éliminer ces variables.

Surveillance automatique des disques externes

Pour un disque interne, on configure smartd qui tourne en permanence. Pour un disque externe qu’on branche occasionnellement, ce modèle ne convient pas : le démon va spammer le journal à chaque débranchement.

La bonne approche, c’est un check à chaque connexion, déclenché par udev.

Le script de check

#!/bin/bash
# /usr/local/bin/check-external-disk.sh

DEVICE="$1"
LOGDIR="/var/log/smart-external"
mkdir -p "$LOGDIR"

# Laisser au pont le temps de s'initialiser
sleep 5

# Récupérer un identifiant unique du disque pour nommer le log
SERIAL=$(sudo smartctl -d auto -i "$DEVICE" 2>/dev/null | \
    grep -i "serial" | awk -F: '{print $2}' | tr -d ' ')
SERIAL=${SERIAL:-unknown}

TIMESTAMP=$(date +%Y%m%d-%H%M%S)
LOGFILE="$LOGDIR/${TIMESTAMP}-${SERIAL}.log"

# Verdict rapide
HEALTH=$(sudo smartctl -d auto -H "$DEVICE" 2>&1)
echo "=== SMART check on $DEVICE at $(date) ===" > "$LOGFILE"
echo "$HEALTH" >> "$LOGFILE"
echo "" >> "$LOGFILE"

# Rapport complet
sudo smartctl -d auto -a "$DEVICE" >> "$LOGFILE" 2>&1

# Alerte si problème détecté
if echo "$HEALTH" | grep -qE "FAILED|Pre-fail"; then
    MSG="Disque externe $DEVICE (S/N $SERIAL) en alerte SMART"
    logger -t external-disk-check "$MSG"

    # Notification desktop si session graphique active
    for user in $(loginctl list-users --no-legend | awk '{print $2}'); do
        uid=$(id -u "$user" 2>/dev/null) || continue
        sudo -u "$user" \
            DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/$uid/bus" \
            notify-send -u critical "Disque externe défaillant" "$MSG" 2>/dev/null
    done
fi

# Garde-fou : ne pas accumuler indéfiniment
find "$LOGDIR" -name "*.log" -mtime +365 -delete

La règle udev

sudo nano /etc/udev/rules.d/99-external-disk-smart.rules

Avec le contenu :

ACTION=="add", SUBSYSTEM=="block", KERNEL=="sd[a-z]", \
    ENV{ID_BUS}=="usb", ENV{DEVTYPE}=="disk", \
    RUN+="/usr/local/bin/check-external-disk.sh /dev/%k"

Puis recharger les règles :

sudo udevadm control --reload-rules

Désormais, chaque fois que vous branchez un disque USB, un check SMART complet est lancé, archivé et vous alerte en cas de problème. Vous vous constituez un historique automatique précieux pour détecter toute dérive entre deux branchements.

Une vue d’ensemble

Pour consulter facilement l’historique :

# Liste des derniers checks
ls -lt /var/log/smart-external/ | head

# Évolution des Reallocated_Sectors pour un disque donné
grep -l "WD-WX12A34BCDEF" /var/log/smart-external/*.log | \
    xargs grep -H "Reallocated_Sector_Ct" | \
    awk '{print $1, $NF}'

Recommandations finales

Sur les disques USB, retenez quatre règles pratiques :

Ne faites pas une confiance aveugle aux indicateurs. Le pont peut tronquer ou mentir. Si quelque chose semble louche (température aberrante, attribut manquant), validez en branchant le disque en SATA direct quand c’est possible.

Évitez les boîtiers bas de gamme pour les données critiques. Un pont à 5€ qui ne transmet pas SMART, c’est un disque dont vous ne saurez jamais qu’il est en train de mourir. Les boîtiers à base de JMicron JMS583 (NVMe) ou ASMedia ASM235CM (SATA) sont devenus abordables et fiables.

Méfiez-vous du chiffrement matériel propriétaire. Sur les WD My Passport et équivalents, le disque est inutilisable sans son pont d’origine. Si le pont tombe en panne, les données sont perdues même si le disque mécanique va bien. Pour des données importantes, préférez un boîtier USB générique avec un disque SATA standard à l’intérieur — vous pourrez toujours sortir le disque et le récupérer en SATA direct.

Automatisez le check à la connexion. C’est le pendant naturel de smartd pour les disques externes. Cinq secondes après chaque branchement, vous savez si tout va bien, et vous avez un historique daté.

Et au-delà de tout ça, ne perdez jamais de vue le principe fondamental : SMART, qu’il fonctionne ou pas à travers USB, n’est pas une garantie. Un disque externe, par nature, voyage, tombe, se déconnecte mal. Il échoue plus souvent qu’un disque interne. La seule vraie protection reste, encore et toujours, la sauvegarde — et même mieux, la sauvegarde redondante.

Article complémentaire au dossier « Surveiller la santé de ses disques sous Linux ». Pour les notions générales sur SMART, les attributs et le calcul d’usure, se reporter au dossier principal.