[Résolu] - Perte des partages lors d'accès via ssh

[chekos]

Bonjour,

 

Je rencontre un problème depuis ce matin, en effet lors de connexions ssh je me suis aperçu qu'outre /volume1 (qui contient mes données), /volume1▒ est apparu et me pose problème car si j'utilise la complétion (ls /volume) ou j'essaie d'y accéder, tous les partages disparaissent et le volume se retrouve avec une taille de 2,2 Go au lieu de 16To.

Un reboot corrige le souci, mais cela est assez génant, quelqu'un saurait comment "virer" ce volume1▒ ?

 

Merci.

Edited March 28, 2016 by Guest

[nicoueron]

Peux-tu faire un screenshot du résultat de ton

ls -ltr

? parceque là comme ça c'est un peu hard ^^

[chekos]

Voici le résultat du ls

 

Diskstation> ls -ltr /
dr-xr-xr-x  213 root     root             0 Jul 16  2015 proc
drwxr-xr-x    9 root     root          4096 Jul 16  2015 usr
drwxr-xr-x   37 root     root          4096 Jul 16  2015 etc.defaults
drwxr-xr-x    2 root     root          4096 Jul 16  2015 bin
drwxr-xr-x    2 root     root          4096 Jul 16  2015 sbin
drwxr-xr-x    2 root     root          4096 Jul 16  2015 lib64
drwxr-xr-x   13 root     root          4096 Jul 16  2015 var.defaults
dr-xr-xr-x   12 root     root             0 Jul 16  2015 sys
drwx------    2 root     root          4096 Nov 12 11:27 lost+found
drwxr-xr-x    2 root     root          4096 Nov 12 11:27 mnt
drwxr-xr-x    2 root     root          4096 Nov 12 11:27 initrd
drwxr-xr-x   11 root     root          4096 Nov 14 11:50 opt
drwxr-xr-x    6 root     root          4096 Mar 16 03:42 volumeUSB2
drwxr-xr-x    5 root     root          4096 Mar 19 19:20 volume1[0m
drwxr-xr-x    4 root     root          4096 Mar 20 02:48 volume1
drwxr-xr-x    4 root     root          4096 Mar 20 02:48 volume1
drwxr-xr-x    4 root     root          4096 Mar 20 02:52 volumeUSB1
drwxr-xr-x   14 root     root         18900 Mar 20 02:52 dev
drwxr-xr-x   30 root     root         36864 Mar 20 02:52 lib
drwxr-xr-x   14 root     root          4096 Mar 20 13:57 var
drwxr-xr-x   41 root     root          4096 Mar 21 15:06 etc
drwxr-xr-x   19 root     root          1240 Mar 21 16:36 run
drwx------    4 root     root          4096 Mar 21 16:53 root
drwxrwxrwt   16 root     root          1440 Mar 21 16:54 tmp

 

A noter que suite à cette commande, les shares ont "disparu" et que toutes les applications sont indisponibles, /volume1 ne contenant qu'un répertoire.

[nicoueron]

Si j'ose dire... essaie de supprimer tout ce qui n'est pas lié à volume1 exactement. Il semble que l'encodage du nom de ce répertoire soit la cause de ton pb. Je ne vois pas pourquoi de tel répertoire se sont créés mais quoi qu'il en soit il serait bon de les dégager. Mais pour le faire il faut connaitre leur nom exact (sans passer par la complétion).

Un truc du type :

rm -R "/volume1[0m"

[chekos]

J'avais déjà essayé, mais je n'ai pas réussi, je ne trouve pas la syntaxe à utiliser pour effacer le répertoire

 

Diskstation> rm -R "/volume1�"
rm: can't remove '/volume1�': No such file or directory

[lilobzh]

le raid a explosé logiciellement non ?

[chekos]

Je ne crois pas, les données sont disponibles après chaque redémarrage, mais dès que je me connecte en ssh/telnet et veut accéder à /volume1, le système "perd" les pédales et je dois redémarrer pour retrouver un fonctionnement "normal".

J'ai pu virer volume1[0m à l'aide de la command find et l'inode du répertoire, par contre il reste volume1 qui a le même inode que volume1 et que je n'ose pas effacer avec la même méthode.

[nicoueron]

Là c'est vrai que ce serait trop risqué. Je pense qu'une réinstallation du DSM pourrait corriger le pb

[chekos]

J'ai lancé un test de cohérence des données hier soir et ai prévu de ré-installer DSM avec une clé USB différente après si le problème n'est pas résolu, j'espère que cela corrigera le problème.

[chekos]

Le problème persiste malgré la "réinstallation/upgrade" avec une clé usb différente.

[JacquesF]

A priori, je pense aussi à un problème d'encodage de caractères.

Tout d'abord, il faudrait vérifier s'il s'agit de plusieurs noms pour le même répertoire, ou de répertoires différents.

Pour ça, un ls -li te donnera le numéro d'inode de chaque dossier, si c'est le même numéro, il s'agit de lien 'hard', et on peut supprimer le dossier en trop normalement sans risque, mais la prudence est quand même conseillée.

Si les numéros sont différents, ce sont 3 dossiers différents.

 

Ce que je ferais, personnellement, c'est arrêter les services de partage, vidéos, photos, musique, etc... pour n'avoir pratiquement que la session SSH.

Ensuite, regarder avec la commande mount ce qui est réellement monté dans volume1, et le démonter avec umount /volume1.

A ce point, le contenu du dossier doit être vide, ou éventuellement un dossier lost+found.

Donc, on ne risque plus de détruire les données en effaçant le répertoire.

 

Ensuite, un :

cd /

rmdir -i volume1*

A chaque fois que la confirmation de suppression est demandée (option -i), on vérifie le nom du dossier pour ne détruire que les mauvais.

 

Je pense que ça devrait te sortir de ton problème.

 

bien entendu, une sauvegarde avant n'est pas inutile !

[chekos]

Salut,

 

Merci pour ces conseils, j'ai enfin pu corriger ce problème en passant les commandes suivantes

 

Diskstation> syno_poweroff_task -d
Diskstation> ls -li
Diskstation> rm -ri volume1*

 

J'ai tenté un umount /volume1 avant le rm, mais ça me renvoyait des erreurs en indiquant que le répertoire n'existait pas.

J'ai également killer "à la main" quelques process (Ubooquity, JDownloader, ...).

 

Merci encore pour votre aide.

[JacquesF]

OK, tant mieux si ça a marché.

On gagne toujours à chercher à connaître les options des commandes, encore plus dans le monde linux.

Il y en a quasiment toujours une qui répond au besoin.

 

Bonne semaine

Jacques

[lilobzh]

cas intéressant en tout cas !