Le point de montage de mon HDD externe "tombe" n'est plus disponible

Support
, ,
1

What type of hardware are you using: Raspberry Pi 3, 4+
What YunoHost version are you running: 12.1.23
How are you able to access your server: SSH
Are you in a special context or did you perform specific tweaking on your YunoHost instance ?: Stockage d’une partie du /home sur un disque dur externe

Describe your issue

Bonjour,
Depuis quelques semaines, j’ai le point de montage de mon disque dur externe (qui contient une partie du repertoire /home de mon serveur) qui tombe de maniere incomprehensible (pour moi)

Pour faire le montage, j’ai suivi la page de la doc : Ajouter un stockage externe à son serveur | Yunohost

A chaque fois que le probleme se produit, je le resouds en refaisant les commandes mount

Mais c’est etonnant, je n’ai pas eut de probleme pendant plusieurs mois et ca n’arrete pas de se produire depuis quelques semaines, mes points de montage tiennent a peine plusieurs heures (peut etre meme pas 1).
En fait j’ai l’impression que mon disque dur se met en veille et ca fait sauter le point de montage.

Je ne pense pas que ca vienne de l’ecriture du fichier /etc/fstab parce qu’apres avoir fait le montage, meme si je reboot mon systeme, le point de montage se refait correctement.

Ca pourrait vouloir dire que le disque dur est en train de mourrir mais smartd n’a pas l’air de remonter quoi que ce soit qui deconne.

Je suis preneur de toutes vos idees et disponibles pour passer les commandes que vous jugerez utiles.

Merci d’avance.

Share relevant logs or error messages

finkelstein@finkelstein:/home/yunohost.app $ sudo dmesg --time-format ctime | grep sda1
[Tue Sep 23 15:00:43 2025] sda: sda1
[Tue Sep 23 15:00:46 2025] EXT4-fs (sda1): recovery complete
[Tue Sep 23 15:00:46 2025] EXT4-fs (sda1): mounted filesystem 33b456e4-1707-4804-87df-973b16354ef4 r/w with ordered data mode. Quota mode: none.

→ Je viens de rebooter

finkelstein@finkelstein:/home/yunohost.app $ cat /etc/fstab
proc /proc proc defaults 0 0
PARTUUID=fb743914-01 /boot/firmware vfat defaults 0 2
PARTUUID=fb743914-02 / ext4 defaults,noatime 0 1

UUID=33b456e4-1707-4804-87df-973b16354ef4 /mnt/hdd auto defaults,nofail 0 0
/mnt/hdd/yunohost/home/yunohost.app /home/yunohost.app none defaults,bind 0 0
/mnt/hdd/yunohost/home/yunohost.backup /home/yunohost.backup none defaults,bind 0 0
/mnt/hdd/yunohost/home/yunohost.multimedia /home/yunohost.multimedia none defaults,bind 0 0
/mnt/hdd/yunohost/var/mail /var/mail none defaults,bind 0 0

2

Une question de gestion de l’alimentation du disque ? Disque alimenté par le RPI ou avec alimentation externe ?

3

A vrai dire, j’ai l’impression que c’est “retombé en marche” depuis mon dernier reboot et j’avoue que ca m’embete un peu.

Tout ce que j’ai fait et constaté depuis c’est
un fsck
et apres le reboot j’ai constaté que le disque etait reconnu sur /dev/sda1 alors que depuis que j’investiguais sur le probleme j’ai vu le disque sur /dev/sdb1 voire /dev/sdc1 alors que lors du premier montage, le disque etait reconnu sur /dev/sda1.

Mais je ne vois pas ce que ca a a voir avec la choucroute puisque dans mon fichier /etc/fstab j’ai bien fait en sorte que le point de montage se base sur l’UUID du disque et non son chemin.

Quoiqu’il en soit, ca fonctionne mais si quelqu’un a une explication, je suis preneur parce que je n’aime pas trop que ca fonctionne alors que j’ai l’impression de n’avoir quasiment rien fait de plus que quand ca ne marchait pas …

4

Bon, il suffit que je vienne dire ici que tout va bien et forcement, ca ne va plus !

Et le comportement que j’avais remarqué vient de se reproduire, HDD est passé (je ne sais pas comment) sous /dev/sb1

finkelstein@finkelstein:~$ sudo lsblk
[sudo] password for finkelstein:
NAME        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
sdb           8:16   0  1.8T  0 disk
└─sdb1        8:17   0  1.8T  0 part
mmcblk0     179:0    0 28.8G  0 disk
├─mmcblk0p1 179:1    0  512M  0 part /boot/firmware
└─mmcblk0p2 179:2    0 28.3G  0 part /

Est ce qu’il existe un moyen de le fixer sur /dev/sda1 ?

5

Le disque est alimenté par une alimentation externe

6

Je crois que l’attribution est dynamique: est-ce que tu as d’autres périphériques branchés en usb ?

7

Regarde peut-être avec dmesg --ctime | grep -i usb si tu trouves des traces de déconnexion du disque.

Il y a une question que je n’ai pas posée : HDD ou SSD (le 1er type j’imagine au vu du nom du montage ?).

8

Il arrive que le nommage lors du boot change les lettres…
Et si tu passes par l’UUID ? Pas mieux ? Plutôt que par /dev/hdXZ ?
C’est souvent ce qui est préconisé dans ce cas :wink:

cf entre autres

1 Like
9

Desole de repondre avec autant de délai.
Je suis deja avec l’UUID, voici mon /etc/fstab

proc            /proc           proc    defaults          0       0
PARTUUID=fb743914-01  /boot/firmware  vfat    defaults          0       2
PARTUUID=fb743914-02  /               ext4    defaults,noatime  0       1
# a swapfile is not a swap partition, no line here
#   use  dphys-swapfile swap[on|off]  for that
UUID=33b456e4-1707-4804-87df-973b16354ef4       /mnt/hdd        auto    defaults,nofail 0       0
/mnt/hdd/yunohost/home/yunohost.app     /home/yunohost.app      none    defaults,bind   0       0
/mnt/hdd/yunohost/home/yunohost.backup  /home/yunohost.backup   none    defaults,bind   0       0
/mnt/hdd/yunohost/home/yunohost.multimedia      /home/yunohost.multimedia       none    defaults,bind   0       0
/mnt/hdd/yunohost/var/mail      /var/mail       none    defaults,bind   0       0
10

Pas fait gaffe, désolé
Perso sur rasp, j’ai des fois le disque usb HD qui laĉhe (en externe j’ai un nvme et un hd).
Il y a deux causes à envisager : la technologie uas non adaptée (tu peux alors demander l’utilisation d’usb-storage a la place, mais ça ne suffit pas toujouros, surtout pour du HD) et le manque d’alimentation (5V, 3.1A, sur chargeur de base de type rasp) produisant des erreurs I/O sur le disque et le faisant crasher parfois.
COmment est branché ton disque ? Quel type ?
Des erreurs dans dmesg (root) ?