LOG#102026.08.02 à 08:465 min de lecture

[RPI4-3] NAS — REMONTER LES DISQUES EXTERNES APRÈS UN ORAGE

Cette fois-ci, je ne vais pas laisser passer. Je vais en parler, ce n'est pas parce que cela fonctionne après une intervention que l'on va taire l'affaire.
L'histoire est simple et se répète, l'absence de feedback, croire que tout va bien, mais en fait non !

Histoire :
En prévision d'un orage, j'ai éteint mes disques durs externes. Je n'ai pas suivi la chaîne d'allumage recommandée et je n'ai pas éteint le Raspberry Pi. Le lendemain, après avoir rallumé les disques durs via leurs interrupteurs dans le hub USB auto-alimenté, ceux-ci n'étaient pas disponibles automatiquement. Sous Windows, les lecteurs étaient visibles, mais affichaient un contenu vide. Comment ça, plus d'espace disque, pas de dossiers ni de fichiers ? Mais que se passe-t'il?

📚 Sommaire

Dépannage

Dans l'interface Web de OVM, tout semblait être OK:
Voici le retour de l'état visuel, signal vert c'est OK, signal rouge c'est PROBLÈME.

🟢 Stockage • Disques
🔴 Stockage • Systèmes de fichiers : Non validé
🟢 Stockage • Dossiers partagés
🟢 Services • SMB/CIFS • Partages

Donc via l'interface web, on n'a pas d'erreurs indiquées par le système et pourtant aucuns disques dur n'a son système de monté. L'écran de la web UI affiche les systèmes de fichiers mais avec propriétés manquantes ou valeurs vides. L'expérience utilisateur du logiciel Open Media Vault pourrait être amélioré. Pour forcer la mise à jour, cette connexion avec la réalité, il faut intervenir manuellement.

Après réflexion, stockage et services pourraient être indiqués en orange parce qu'au final, ils dépendent de ce qui précède :

🟠 Stockage • Dossiers partagés
🟠 Services • SMB/CIFS • Partages

Pas d’ERREUR !?! Par le manque d'affichage visuelle d'une erreur et de son explication, l'expérience utilisateur est dégradée !

Sous windows, les lecteurs étaient accessibles, mais vide.

Cela fonctionne ? Presque ? Pas vraiment...

Il faut donc remonter les disques avec leur système de fichier. Il faut intervenir manuellement. Après quelques recherches dans la documentation de base, et l'interrogation d'un modèle LLM, j'ai été renseigné de la solution. En utilisant la commande sudo mount -a, on règle le problème utilisateur.

sudo : Exécute la commande avec les privilèges d'administrateur (Root).
mount : L'outil Linux pour lier un périphérique (disque dur, clé USB, partage réseau) à un dossier du système.
-a (All) : Demande au système de monter tous les disques configurés dans le fichier de configuration /etc/fstab. Cela sert souvent à tester si une nouvelle configuration de disque fonctionne sans redémarrer.
/etc/fstab est un fichier au format texte brut structuré en six champs alignés par des espaces ou des tabulations. Sa syntaxe stricte par ligne est : <périphérique> <point_de_montage> <type_système_fichiers> <options_de_montage> <dump> <fsck>. Toute ligne commençant par un dièse (#) est un commentaire ignoré par le système.

Comme cela a fonctionné, une fois les disques remontés par le système, sous windows les lecteur connectés via le service Samba, affichent enfin leur contenu et des données réelles de l'espace disque occupé ou disponible.

Euréka ! Les disques durs fonctionnent complètement, les données sont accessible en lecture et écriture ! Dossiers et fichiers peuvent être créés !

Explication technique

La commande mount est utilisée lorsque vous voulez remonter manuellement toutes les unités de stockage sur votre système. Quand vous utilisez cette commande, le système lit les informations du fichier de configuration, trouve les parties correspondantes et les monte. Une fois le disque monté, le service SMB (Samba) retrouve rapidement ses dossiers et les affiche sous Windows, attention ! Affiche quelque chose de fonctionnel, pas un lecteur vide avec des statistiques de sotckage saugrenues.

Voici 2 diagrammes de séquences d'allumage :

Séquence d'allumage recommandée

graph LR
    A[🖥️ Éteindre Raspberry Pi] --> B[💾 Éteindre disques durs]
    B --> C[⚫ Tout éteint]
    C --> D[💾 Allumer disques durs]
    D --> E[🖥️ Allumer Raspberry Pi]
    E --> F[✅ Système OK]

Séquence d'allumage qui ne fonctionne pas

graph LR
    A[💾 Éteindre disques durs] --> B[🖥️ Raspberry Pi allumé]
    B --> C[💾 Allumer disques durs]
    C --> D[❌ Problème : Fichiers non montés]
    D --> E[🔧 Solution : `sudo mount -a`]

et oui un diagramme vaut parfois milles images.

Si j’avais d’abord éteint le Raspberry Pi, puis les disques durs, au redémarrage, en allumant d’abord les disques durs puis le Raspberry Pi, tout aurait fonctionné correctement. Mais comme je n’ai pas suivi cette séquence, j’ai dû intervenir manuellement via SSH.

Conclusion

Mon expérience démontre deux choses. Si les disques durs externes s'éteignent d'une manière ou d'une autre, manuellement ou par coupure de courant, cela peut perturber le fonctionnement d’un Raspberry Pi avec OVM et Samba. Heureusement, en utilisant la commande sudo mount -a, j’ai pu remonter le système de fichiers et résoudre le problème. Désormais, je suivrais le bon protocole d'allumage, et si une panne apparait, je sais exactement quoi faire.

Puisque c’est faisable manuellement, il est très probable que je puisse aussi automatiser ce processus en gardant le Raspberry Pi allumé pour éviter toute intervention manuelle au redémarrage : Automatiser des tests et remonter les disques dur via une tâche automatisée.

En conclusion, je vois vert et c'est très positif !

🟢 Stockage • Disques
🟢 Stockage • Systèmes de fichiers
🟢 Stockage • Dossiers partagés
🟢 Services • SMB/CIFS • Partages


#User