HELP volume ramené a 1.35GO

[devildant]

Bonjour,

 

je vous contacte car j'ai un souci qui est apparie d'un coup, mon volume a été ramené a 1.35go au lieux de 27TO,

quand je me connecte en ssh je vois un volume étrange :

 volume1     volume1▒

je ne sais plus trop quoi faire  la panique me submerge 

 

pouvez vous m'aider?

 

Modifié le 22 juin 2015 par devildant

[devildant]

j'ai fait faut un df après un reboot et j'ai bien mon volume 1 de monté 

$> df -h
Filesystem               Size  Used Avail Use% Mounted on
/dev/root                2.3G  832M  1.4G  38% /
/tmp                     2.9G  796K  2.9G   1% /tmp
/run                     2.9G  3.2M  2.9G   1% /run
/dev/shm                 2.9G     0  2.9G   0% /dev/shm
none                     4.0K     0  4.0K   0% /sys/fs/cgroup
/dev/bus/usb             2.9G  4.0K  2.9G   1% /proc/bus/usb
/dev/mapper/vol1-origin   27T   16T   12T  57% /volume1

 

mais des que je fait un ls / ou un cd /volume1 voila se que me renvoi le df 

$> df -h
Filesystem               Size  Used Avail Use% Mounted on
/dev/mapper/vol1-origin  2.3G  832M  1.4G  38% /volume1
/tmp                     2.9G  796K  2.9G   1% /tmp
/run                     2.9G  3.2M  2.9G   1% /run
/dev/shm                 2.9G     0  2.9G   0% /dev/shm
none                     4.0K     0  4.0K   0% /sys/fs/cgroup
/dev/bus/usb             2.9G  4.0K  2.9G   1% /proc/bus/usb

 

 

[Fenrir]

si je comprends bien :

1. tu te connecte en ssh
2. tu fais : df -h
3. tu as /dev/mapper/vol1-origin   27T   16T   12T  57% /volume1
4. puis tu fais : cd /n'importe où
5. et df te renvoi /dev/mapper/vol1-origin  2.3G  832M  1.4G  38% /volume1

=>plus de /dev/root ?

• C'est un synology ?
• Non modifié ?

Pourrais tu faire une capture de la fenêtre SSH où il y a  : volume1     volume1▒

[devildant]

Bonjour,

deja merci d'avoir répondu.

 

en gros si j'ai le malheur de fair ls / mon volume saute. je peux faire les cd que je veux du moment que le ne fait pas cd /volume1 ca tiens.

ci joint le screen

[devildant]

et sinon oui c'est un synology non modifié

Modifié le 22 juin 2015 par devildant

[devildant]

si je veux recup mon volume je suis obligé de reboot.

[Fenrir]

il est possible que le pb viennent du dossier nommé volume1▒

Le caractère spécial doit être mal interprété (c'est probablement un caractère de contrôle).

J’aurai bien une manip à te proposer, mais aucune idée de comment le syno va réagir, même si ça ne supprimera rien, donc assure toi d'avoir un backup des données (16To de backup ça commence à faire).

Mais avant, commence par poster le résultat de la commande mount

[devildant]

voici le résultat de la commande mount apres un reboot avec mon volume de 27 to de monté : 

mount
/dev/root on / type ext4 (defaults)
/sys on /sys type sysfs (0)
none on /dev/pts type devpts (gid=4,mode=620)
/tmp on /tmp type tmpfs (0)
/run on /run type tmpfs (rw,nosuid,nodev,relatime,mode=755)
/dev/shm on /dev/shm type tmpfs (rw,nosuid,nodev,relatime)
none on /sys/fs/cgroup type tmpfs (uid=0,gid=0,mode=0755,size=4k)
/dev/bus/usb on /proc/bus/usb type bind (bind)
none on /sys/kernel/debug type debugfs (0)
/dev/mapper/vol1-origin on /volume1 type ext4 (usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,synoacl)
securityfs on /sys/kernel/security type securityfs (0)
/dev/sdu1 on /volumeUSB1/usbshare type ext4 (nodelalloc,synoacl)

 

[devildant]

oui ca va etre long a backup  
une idée de se qui se passe? je ne comprends pas d'ou sort se volume avec le caractère étrange

[devildant]

la seul chose que j'ai fait dernièrement c'est de jouer avec docker 

[Fenrir]

J'ai aussi docker installé avec quelques instances et je n'ai pas de soucis.

Essaye ceci :

1. coupes tous les services (smb, nfs, webdav, ...) sauf le ssh
2. arrête toutes les appli/packet (docker, *station, ...)
3. démonte/eject tout ce qui peut l'être (usb, volumes distants, ...)
4. puis en ssh (le danger réside ici, le caractère de contrôle peut avoir une mauvaise interaction avec mv)

mkdir /0bug
mv /volume1* /0bug/

Normalement ça devrait faire une erreur sur /volume1 (il ne peut pas déplacer un volume monté) et déplacer le dossier /volume1▒ dans /0bug

Si tu n'as pas de chance, l'inverse va se produire, il faudra alors renommer le dossier volume1▒ en volume1.

Si ça ne corrige pas le problème, on tentera autre chose

[devildant]

j'ai un peux la trouille pour etre franc ^^

j'ai regardé les log en attendant et voici ce que j'ai trouvé :

 [UPS] Check Safe Mode Done.
Jun 20 13:42:42 XXX syno_poweroff_task: servicecfg_internal_lib.c:501 Failed to exec [/usr/syno/etc/rc.sysv/sftp.sh] [reload][0x2000 bdb_get.c:102]
Jun 20 13:42:42 XXX syno_poweroff_task: servicecfg_internal_lib.c:435 Failed to restart/reload service [sftp][0x2000 bdb_get.c:102]
Jun 20 13:42:42 XXX syno_poweroff_task: servicecfg_internal_lib.c:355 skip reload stopping/stopped job [avahi][0xD300 servicectl_job_reload.c:42]
Jun 20 13:42:42 XXX syno_poweroff_task: servicecfg_internal_lib.c:355 skip reload stopping/stopped job [afpd-avahi][0xD300 servicectl_job_reload.c:42]
Jun 20 13:42:42 XXX syno_poweroff_task: servicecfg_internal_lib.c:355 skip reload stopping/stopped job [netatalk][0xD300 servicectl_job_reload.c:42]
Jun 20 13:42:42 XXX syno_poweroff_task: servicecfg_internal_lib.c:355 skip reload stopping/stopped job [smbd][0xD300 servicectl_job_reload.c:42]
Jun 20 13:42:42 XXX syno_poweroff_task: usb_set_disk_standby.c:65 [sdu] doesn't support sleep ioctl
Jun 20 13:42:42 XXX syno_poweroff_task: usbbkp_hot_pull_out.c:86 Fail to set standby for usb device [sdu], or it doesn't support sleep.
Jun 20 13:42:42 XXX syno_poweroff_task: space_snapshot_origin.c:379 Deleting snapshot-origin of /dev/vg1000/lv fail
Jun 20 13:42:42 XXX syno_poweroff_task: virtual_space_implement.c:230 failed to remove snapshot-origin /dev/vg1000/lv
Jun 20 13:42:42 XXX syno_poweroff_task: virtual_space_implement_op_lib.c:413 Failed to unload [/dev/mapper/vol1-origin] of [/dev/vg1000/lv]
Jun 20 13:42:42 XXX syno_poweroff_task: virtual_space_unload_all.c:55 Failed to unload vspace by implement
Jun 20 13:42:42 XXX syno_poweroff_task: syno_poweroff_task.c:343 Failed to unload all virtual space on space [/dev/vg1000/lv] of [/volume1] [0xD300 servicectl_job_reload.c:42]
Jun 20 13:42:42 XXX syno_poweroff_task: lvm_poweroff.c:56 Failed to /sbin/vgchange -an
Jun 20 13:42:42 XXX syno_poweroff_task: raid_stop.c:29 Failed to mdadm stop '/dev/md2'

 

j'ai eu une prise qui a grillé se week end, cela pourrait être la cause de mon souci?

Modifié le 22 juin 2015 par devildant

[devildant]

merci en tout cas de ton aide

 

[Fenrir]

Pour être franc, il y a peu de chance que le mv casse quoique ce soit, mais comme :

1. tu n'as pas de backup
2. ce n'est pas mon nas
3. encore moins mes données
4. je n'ai presque aucune info sur ce qui a été fait dessus (paquets, custo, ...)
5. je n'ai même pas le modèle
6. et que je n'y ai pas un accès direct

je préfère dire que c'est "potentiellement" dangereux, en gros je ne veux pas assumer la moindre responsabilité

S'il c'était s'agit de mon nas, j'aurai tapé la commande directement car :

1. avec un accès physique aux disques, je suis presque certain de m'en sortir.
2. j'ai un backup de 100% des données

[devildant]

Bonjour, 

oui oui je comprends bien  dans tout les cas le seul responsable c'est moi si jamais il y a un problème si je tente la manip

aprèsje suis dev mais je n'ai aucune competence dans le sys du moins en se qui concerne le raid, du coup je pref bien reflechir avant de tenté des chose que je ne maitrise pas.

la chose qui me dérange le plus c'est l'erreur  de  démontage du volume quand le nas rentre en mode secu après une coupure de courant.

je soupçonne le faite que j'ai shared certain dossier comme le dossier vidéo avec mon container, ce qui pourrais être la cause du problème de démontage.

Du coup je me dit que faire une demande de support pourrai servir si jamais il y a un souci de ce genre ^^

et sinon, j'ai un backup sur un autre syno mais il est pas a jour (forcement :)) du coup en attendant jai lancé la copie.

pour le model c'est ds3612xs, avec les package svn, photostation, dns, docker, mailserver cloud...

concernant les custo rien de particulier...

[Fenrir]

je soupçonne le faite que j'ai shared certain dossier comme le dossier vidéo avec mon container, ce qui pourrais être la cause du problème de démontage.

C'est une info importante que j'aurai aimé avoir depuis le début

Oui c'est très probablement la cause de tes soucis, tu as du louper ton montage dans le conteneur.

Essaye de stopper le conteneur/désactiver (pour qu'il ne démarre plus au reboot) puis reboot ton syno, arrete un maximum de services et exécute directement les commandes (sans faire de cd ou de ls)

Si tout se passe bien (que tu as bien tes données dans /volume1 et que tu y accède depuis filestation), reboot, puis fais : du -sh /0bug et post le résultat ici

Sinon, ne reboot pas et annule le mv avec

mv /0bug/* /.

[devildant]

C'est une info importante que j'aurai aimé avoir depuis le début

Oui c'est très probablement la cause de tes soucis, tu as du louper ton montage dans le conteneur.

Essaye de stopper le conteneur/désactiver (pour qu'il ne démarre plus au reboot) puis reboot ton syno, arrete un maximum de services et exécute directement les commandes (sans faire de cd ou de ls)

Si tout se passe bien (que tu as bien tes données dans /volume1 et que tu y accède depuis filestation), reboot, puis fais : du -sh /0bug et post le résultat ici

Sinon, ne reboot pas et annule le mv avec

mv /0bug/* /.

merci de ton retour,

oui pour le container je n'ai réalisé que après, j'avais fait de simple -v /volume1/video pour mappé mon container en suivant la doc docker, donc je vois pas ce que j'ai pu faire de mal :(.

pour docker je l'ai désinstallé dés que j'ai pensé a ça.

 

[devildant]

Bon a priorie cloudsync a fait des sienne et du coup  mon volume foireux de est full 2.3go rrrrr

Modifié le 23 juin 2015 par devildant

[devildant]

Bonjour, alors voici un petit retour sur ma mésaventure.

j'ai au final effectuer un double reset, mais avant j'ai quand même tenté ta manip Fenrir, mais j'ai un peux triché

donc si jamais cela vous arrive :

1) changé l'encode de putty et pour que le volume qui prose problème est un nom affichable, dans mon cas je suis passé de utf-8 a ISO (LATIN-1 West europe)

2) faire un ls sur / pour avoir le nom du volume, dans mon cas cetait volume1Â

3)  reboot le nas pour recup le volume

4) mkdir /0dev

5) mv /volume1Â /0dev/

maintenant la raison de mon double reset j’avais la partition dev full et mon interface DSM était partiellement en français partiellement en anglais et des paramètre avaient sauté, donc j'ai préféré tout remettre au propre.

 

voila encore un grand merci a Fenrir

 

Cordialement,

[Fenrir]

bien vu pour l'encodage, j'aurai du te l'indiquer.