Aller au contenu

narfight

Membres
  • Compteur de contenus

    31
  • Inscription

  • Dernière visite

À propos de narfight

narfight's Achievements

Newbie

Newbie (1/14)

0

Réputation sur la communauté

  1. Bonjour à tous, Mon NAS TS-563-8G ne veut plus démarrer. au niveau de la face avant, quand j'appuie sur "Power", la Led "USB" s'allume 1s en bleu et la Led "STATUS" reste en permanence verte. Les ventilateurs ne s'activent qu'un bref moment et les disques dur ne démarre pas. J'ai tenté de débrancher le NAS pendant 30 minutes et d'enlever toutes les disques mais cela ne change en rien le comportement du NAS. J'ai également appuyé sur le bouton "Reset" mais en vain. Je ne trouve pas d'information sur ce genre de problème sur Google. Pouvez-vous m'aider ? Merci d'avance
  2. L’extension semble avoir été interrompue par une erreur de reconstruction. Le log est très light sur les détails. La vérification de la cohérence que j'ai lancé le 2/9 à 14h c'est finie ce 4/9 à 6h30 et n'a retourné aucune erreur. Je penses que les problèmes sont dorénavant derrière moi. Merci en tout cas pour les retours et les conseils utiles.
  3. Je vais un peu regarder dans les logs mais il a eu un lourd historique lors du passage des 2TO aux 4TO. Pendant la reconstruction du volume, un disque dur à été éjectés par erreur en pensant que l'opération était finie (ne surtout pas se fier au gros V vert qui dit que tout vas bien). Je me suis donc retrouver avec le volume en erreur, le Synology qui ne rebootait plus quand j'avais plus de 3 disques sur 5 dans le boitier. Bref j'ai eu chaud à plusieurs reprise et au final je n'ai rien perdu !!! Il n'est pas impossible qu'il ai quand même eu des séquelles quelque part. En tout cas, actuellement j'ai lancé un test d'intégrité sur l’ensemble du volume histoire de repartir sur une bonne base.
  4. Super, c’était le cas du "volume multiple sur RAID". Merci beaucoup pour ton aide ! Narfight
  5. Bonjour à tous, Je viens de finir la migration de 5*2TB à 5*4TB et là, grosse déception. Je n'ai pas 14TO de données utile mais 9.5TO !!!! A-t-il donc une limitation quelque part sachant que je suis bien en EXT4 sous DSM 5.0-4493 Update 4 sur un DS1511+ ? Merci d'avance pour votre confirmation. Narfight
  6. Merci beaucoup pour cette information :-)
  7. Bonjour à tous, Quand j'ai reçu mon DS1511+ (en version 3 et il a longtemps), il était limité à des disques dur de 3 To. Pouvez-vous me dire si cette limitation a évoluée avec les mise à jours du DSM en 5 ? Je penses que non mais je voudrais votre avis. Bien à vous, Narfight
  8. Pour info, je suis sur Windows 8.1 et vous ?
  9. Cela me rassure en partie, l'information ne peut être que fausse ! Ce n'est pas de l'espace perdu. Je vais voir pour ouvrir un bug chez Synology
  10. Bonjour à tous, J'ai voulu faire un peu de ménage dans ma musique et j'ai constaté ceci sur un volume en ext4 en RAID5: Soit 31Go de perdu pour seulement 412mo de stockages de 66 fichiers ..... c'est monstrueux, cela représente 78% de perte d'espace. Ces valeurs sont elles fiables ? A-t-il un moyen de réduire cette perte ? Avez-vous constaté la même chose ? Merci d'avance, Narfight
  11. Bonjour tout le monde. Nous sommes 3 personnes à avoir un syno et nous voudrions mettre en place une sauvegarde de nos données dupliquées sur les deux autres Syno. Vient l'idée du BitTorrent Sync qui me semble parfait pour ce genre de cas sauf que nous voudrions crypter les données avant de les envoyer. J'utilisais avant un dossier crypté et le système de sauvegarde de Synology mais ici, cela ne fonctionne pas !!! Quelqu'un aurait-il une idée ? Merci d'avance !
  12. Bien vu ! J’étais aussi tombé à zéro jour de rétention. Merci à toi
  13. Je me demande si ce n'est pas un bug qui est corrigé dans la version 0.7.5 :
  14. J'ai le même problème depuis la dernière update du pack SabNZBd
  15. Bonjour tout le monde, Je tente de faire l'update de CPS mais sans y arriver. Suite à la lecture des logs, je me suis dits que le répertoire temp_updater n’était pas créé et q'il n'avait pas suffisamment de droit mais il existe déjà avec un répertoire nommé "RuudBurger-CouchPotatoServer-eb30dff". Voici quelques autres info technique : Version : 9312336962ecb06071502e9d033f83aff8471a3f (Sun, 23 Sep 2012 23:36:59 GMT) Updater : source ID : 15561 Version de l'APK : 20120830-1 Synology : DS1511+ DSM : 4.1-2636 (que je suis en train d'upgrader en 4.1-2647) Pouvez-vous me dire comment réparer l'update ? Merci d'avance ! 10-13 09:58:54 ERROR [hpotato.core.plugins.base] Unable to create folder "/usr/local/couchpotatoserver/var/cache/temp_updater": string index out of range 10-13 09:58:55 ERROR [potato.core._base.updater] Failed updating: Traceback (most recent call last): File "/volume1/@appstore/couchpotatoserver/share/CouchPotatoServer/couchpotato/core/_base/updater/main.py", line 267, in doUpdate tar.extractall(path = extracted_path) File "/usr/local/python/lib/python2.7/tarfile.py", line 2048, in extractall self.extract(tarinfo, path) File "/usr/local/python/lib/python2.7/tarfile.py", line 2085, in extract self._extract_member(tarinfo, os.path.join(path, tarinfo.name)) File "/usr/local/python/lib/python2.7/tarfile.py", line 2161, in _extract_member self.makefile(tarinfo, targetpath) File "/usr/local/python/lib/python2.7/tarfile.py", line 2201, in makefile copyfileobj(source, target) File "/usr/local/python/lib/python2.7/tarfile.py", line 266, in copyfileobj shutil.copyfileobj(src, dst) File "/usr/local/python/lib/python2.7/shutil.py", line 49, in copyfileobj buf = fsrc.read(length) File "/usr/local/python/lib/python2.7/tarfile.py", line 819, in read buf += self.fileobj.read(size - len(buf)) File "/usr/local/python/lib/python2.7/tarfile.py", line 737, in read return self.readnormal(size) File "/usr/local/python/lib/python2.7/tarfile.py", line 746, in readnormal return self.fileobj.read(size) File "/usr/local/python/lib/python2.7/gzip.py", line 256, in read self._read(readsize) File "/usr/local/python/lib/python2.7/gzip.py", line 303, in _read self._read_eof() File "/usr/local/python/lib/python2.7/gzip.py", line 342, in _read_eof hex(self.crc))) IOError: CRC check failed 0xca4082d7L != 0x591caf41L
×
×
  • Créer...

Information importante

Nous avons placé des cookies sur votre appareil pour aider à améliorer ce site. Vous pouvez choisir d’ajuster vos paramètres de cookie, sinon nous supposerons que vous êtes d’accord pour continuer.