Jump to content
XPEnology Community

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


chekos

Recommended Posts

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 by Guest
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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"

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 !

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

×
×
  • Create New...