Fravadona

Dommage que se soit un processeur ARM, j'aurais pu te trouver un binaire "sort -V" pris dans un Linux PC compatible avec DSM

Je conseille plutot l'utilisation du RAID NON-SHR pour la raison suivante : si ton Syno meurt et que tu dois recuperer tes donnees a partir d'un PC Linux en branchant les disques du NAS dessus, alors tu n'auras aucun soucis s'il ont ete configures en RAID traditionnel sur le NAS, alors qu'en SHR ... bonjour la prise tete !!! Oui c'est grave lol, en faisant ca tu reduits une bonne partie de la duree de vie de la batterie de l'onduleur

A priori il te manque les librairies POSIX Thread, ou alors tu n'as pas bien defini les LD_LIBRARY_PATH et INCLUDEPATH, que du bonheur !! Je repose la question, tu as quel Synology ? Un modele Intel ?

A mon avis ce n'est pas une bonne idee de changer la version php du Syno, ca risque de rendre l'interface DSM inutilisable

Prends plutot un boitier USB3 qu'un USB2, et ca pourra aussi servir a sauvegrader ton Syno

Une fois qu'un disque a ete configure par le Syno tu ne perds pas ce qu'il y a dedans lors d'ajout d'autre disques (ou alors il te previent de l'effacement, si tu change de configuration RAID par exemple)

Ca ressemble a un probleme de configuration de passerelle ou de DNS

Oui c'est possible si tu as un boitier externe pour tes disques qui contiennent tes donnees car si tu les places a l'interieur du Syno, il va les reformater. Il te faut donc un autre disque, de capacite suffisante pour contenir les donnees d'un de tes Green, et un boitier externe USB3 pour faire le transfert

As-tu un processeur intel sur ton NAS ?

Relancer le service de partage upnp ? Re-indexer ?

Donc : - la taille des secteurs est de 512 octets - le superblock (metadonnees RAID) se reserve 2048 secteurs au debut de la partition. - le chunk size (la taille des blocks RAID) correspond a 64K / 512 = 128 secteurs Maintenant on peut verifier la combinaison reelle des disques dans le RAID 10 en prelevant le premier block de donnees de chaque disque et en les comparant (ca n'avait pas fonctionne la premiere fois car je n'avais pas pris en compte le superblock). dd if=/dev/hda3 of=/root/b_hda bs=512 skip=2048 count=128 dd if=/dev/hdc3 of=/root/b_hdc bs=512 skip=2048 count=128 dd if=/dev/sdb3 of=/root/b_sdb bs=512 skip=2048 count=128 dd if=/dev/sdd3 of=/root/b_sdd bs=512 skip=2048 count=128 diff -q /root/b_hda /root/b_hdc diff -q /root/b_hda /root/b_sdb diff -q /root/b_hda /root/b_sdd diff -q /root/b_sdb /root/b_sdd Cette fois le test devrait etre probant (s'il n'y a pas eu d'ecritures sur les disques pendant que tu lancais les commandes "dd") Synology a peut-etre modifie son layout RAID, donc tu prends un risque en ne verifiant pas que tes disques ont vraiment la configuration qu'ils sont supposes avoir avec un "Layout near=2"

Pour acceder aux partages dans l'explorateur la syntaxe est quelque chose du genre ip_du_nas

Je ne suis pas partisant du chiffrement des disques pour deux raisons : - Ca complique tout pour la recuperation en cas de panne - Ca ne protege pas autant que l'on peut croire contre quelqu'un qui veut vraiment y acceder

La veille des disques durs est-elle active ? Un disque qui prend trop de temps au retour de veille peut causer ce genre de soucis pour un RAID

Oui mdr, c'est juste impossible : tu as oublie le ~ qui correspond a la racine de ton compte utilisateur Mais si tu ne veux pas d'aide alors je n'y peux rien PS: J'ai teste la connexion au NAS a partir de Safari sous Mavericks, en http, et no problem pour enregistrer le user/mdp, donc @+

Et ton iPhone/Andoid aussi ?

Oui tu ne peux pas faire grand chose contre quelqu'un avec acces physique a un systeme informatique

Essaies d'ajouter l'option "vers=3" dans le montage fstab

Alors peut-etre un probleme avec ton profil Safari ? Tu peux tenter d'en faire un nouveau : - Quitter Safari - Terminal> mv ~/Library/Safari ~/Library/Safari.bak - Lancer Safari Et pour restaurer l'ancien profil : - Quitter Safari - Terminal> rm -rf ~/Library/Safari - Terminal> mv ~/Library/Safari.bak ~/Library/Safari - Lancer Safari Ca ne tue pas d'essayer, au moins pour voir si ca vient de la Pour ma part je vais essayer demain sur une station Mavericks pour voir si j'arrive a sauver les mdp avec Safari.

Ca c'est une erreur de ma part, il y a un superblock ou le RAID stocke les metadata de la partion, ca se complique un peu On va avoir besoin des resultats des commandes fdisk -l /dev/hda et mdadm --examine /dev/hda3 ================================================================================== Avec ces numeros de serie, et en regardant sur DSM dans "Start Menu -> Storage Manager -> Hdd Management -> Disk Info" (pour les disques 1, 2 ,3, 4), tu vas pouvoir faire la correspondance entre les "/dev/xxx" et le numero de baie sur le NAS =========================================================================================== Normalement les "/dev/hdX" sont des peripheriques sur nappe IDE alors que les "/dev/sdX" sont des peripheriques sur SATA/SAS/SCSI Je pense que Synology a modifie les drivers dans son noyau Linux de DSM et maintenant ces noms sont maintenant affectes "au pif" Moi si je reboote ces noms changent dans mon RAID6

Ca doit venir du certificat SSL qui n'est pas signe avec une CA connue, mais il suffit de l'ajouter dans les CA de confiance.

Regardes du cote de "tune2fs", tu dois avoir des options pour les ACL etendus Syno> tune2fs -l /dev/md2 tune2fs 1.42.6 (21-Sep-2012) Filesystem volume name: 1.41.10-2228 Last mounted on: /volume1 Filesystem UUID: 14030eb7-91af-4f24-8829-7fc62d94b86a Filesystem magic number: 0xEF53 Filesystem revision #: 1 (dynamic) Filesystem features: has_journal ext_attr resize_inode filetype needs_recovery extent 64bit sparse_super large_file huge_file uninit_bg dir_nlink extra_isize Filesystem flags: signed_directory_hash Default mount options: (none) Filesystem state: clean Errors behavior: Continue Filesystem OS type: Linux Inode count: 365404160 Block count: 1461594192 Reserved block count: 25600 Free blocks: 1089672052 Free inodes: 365236111 First block: 0 Block size: 4096 Fragment size: 4096 Reserved GDT blocks: 8189 Blocks per group: 32768 Fragments per group: 32768 Inodes per group: 8192 Inode blocks per group: 512 Filesystem created: Thu May 31 03:43:23 2012 Last mount time: Sun Nov 3 13:50:56 2013 Last write time: Sun Nov 3 13:50:56 2013 Mount count: 25 Maximum mount count: 20 Last checked: Thu May 31 03:43:23 2012 Check interval: 15552000 (6 months) Next check after: Tue Nov 27 02:43:23 2012 Lifetime writes: 1819 GB Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) First inode: 11 Inode size: 256 Required extra isize: 28 Desired extra isize: 28 Journal inode: 8 Default directory hash: half_md4 Directory Hash Seed: 3ab488e1-7ec6-4eee-9479-c625d4e06ef0 Journal backup: inode blocks

Si tu rentres l'IP du NAS directement dans l'explorateur ca donne quoi ?

A priori ton RAID 10 correspond a /dev/md2 : Le "Layout" (ici "near=2") correspond a l'arrangement des disques dans le RAID 10 Mais je dois regarder la doc plus en detail pour pouvoir en dire plus D'apres plusieurs sources dont http://www.ilsistemista.net/index.php/linux-a-unix/35-linux-software-raid-10-layouts-performance-near-far-and-offset-benchmark-analysis.html?start=1 : On devrait avoir "/dev/hda" en mirroir avec "/dev/hdc" , et "/dev/sdb" en mirroir avec "/dev/sdd" Maintenant il reste a trouver la correspondance avec les slots physiques du NAS. Pour ca on peut utiliser les numeros de serie (et la gestion des disques sur DSM): hdparm -I /dev/hda /dev/hdc /dev/sdb /dev/sdd | grep -e "/dev/" -e "Serial Number" -------------------------------------------------------------------------------------------------------------------------------------------- Bon, c'est bien beau tout ca mais il faut tout de meme verifier... On preleve un morceau du debut de chaque disque : dd if=/dev/hda3 of=/root/hda_1M bs=1M count=1 dd if=/dev/hdc3 of=/root/hdc_1M bs=1M count=1 dd if=/dev/sdb3 of=/root/sdb_1M bs=1M count=1 dd if=/dev/sdd3 of=/root/sdd_1M bs=1M count=1 puis on les compare : diff -q /root/hda_1M /root/hdc_1M diff -q /root/hda_1M /root/sdb_1M diff -q /root/hda_1M /root/sdd_1M La premiere commande "diff" ne devrait rien donner alors que les 2 suivantes devraient retouner "Files xxx and xxx differ"

N'oublies pas que ca peut aussi etre un bug dans ton code C, tu devrais consulter l'utilisation CPU/Memoire pendant que Screen tourne