Aller au contenu

M@ttew

Membres
  • Compteur de contenus

    40
  • Inscription

  • Dernière visite

Réputation sur la communauté

0 Neutral

1 abonné

À propos de M@ttew

  • Rang
    Qnapeur officiel

Profile Information

  • Location
    Martinique
  • Gender
    Male
  • Matériel
    TS-119
  1. Bonjour Philippe, Suite à divers changements internes, je dois migrer mon "application" sur un nouveau NAS, le TS-131. Et malheureusement, je ne parviens pas à installer le QPKG Optware. Impossible de le trouver dans le AppCenter… J'ai donc visité le site http://ipkg.nslu2-linux.org/feeds/optware mais je ne sais pas quelle version de processeur choisir?!… Voir ma version: Linux NASECD6BA 3.2.26 #2 SMP Fri Sep 1 05:40:39 CST 2017 armv7l unknown CPU: Freescale ARMv7 Cortex-A9 dual-core 1.2GHz processor Etant donné ce que je souhaite faire, je n'ai besoin que de "su", mais avoir les "coreutils" ne serait pas mal non plus… Donc si vous avez la méthode pour parvenir à mes fins, j'en serais ravi! Merci, M@ttew
  2. Merci pour toutes ces informations. A moi de jouer désormais. Je reviendrai vers vous au besoin et pour porter le résultat des manipulations… Merci, @+, M@ttew
  3. Merci pour ces précisions. Pour info, j'ai effectué de nouveaux tests ce matin, voici ce que donne Qfinder avec un nouveau disque dur: J'en déduis donc que le NAS est fonctionnel, et que mes déboires proviennent du disque dur WD20EFRX. Pouvez-vous m'en dire plus sur comment installer lvm2 et mdadm sur mon Linux Mint? Pensez-vous malgré tout que je puisse "réparer" le secteur défectueux qui apparait être la source de mon problème? En effet, je faisais tourner quelques services Web sur le NAS, et le seul accès au système de fichiers ne me permettra pas de tout récupérer… Pour info, j'avais pris contact avec le service QNAP France vendredi, et ils m'ont répondu ce matin! Très efficace… Mais mon diagnostic d'alors n'était pas encore aussi précis. Ils m'ont donc invité à faire une demande de RMA. Merci à eux! @+, M@ttew
  4. Bonjour, J'ai parcouru rapidement le forum sans réellement trouver une solution à mon problème. Je possède un TS-131 (mono-baie donc) avec un disque WD Red WD20EFRX depuis 14 mois, qui fonctionnait parfaitement jusqu'à ce que je l'éteigne pour 3 semaines _ le temps de mes vacances d'été… A mon retour, impossible de démarrer le NAS, le bouton on/off est inopérant. Pas de bip, pas de lumière. J'ai testé l'appui pendant 3 et 10 sec, sans résultat. En tendant l'oreille, je perçois un bip au bout de 10 sec comme lors d'un démarrage standard, mais avec un volume très faible (oreille collée au boitier). J'ai tenté de démarrer le boîtier sans disque, sans succès. La carte réseau est alimentée car les diodes oranges/vertes clignotent au branchement de l'alimentation. J'ai changé l'alimentation (3A-12V-36W) pour celle de mon TS-121 qui fonctionne, sans succès. En désespoir de cause, j'ai monté un autre WD20EFRX (formaté en HFS+ Apple), et là, miracle, le NAS démarre. Les diodes s'allument, bip de démarrage, puis ça clignote rouge. J'en déduis qu'il veut formater le disque inconnu pour y installer le firmware _ opération que j'ai avorté ne souhaitant perdre les données de ce second disque. Finalement, j'en déduis que le boîtier NAS fonctionne, et que le problème est à chercher du côté du disque dur… J'ai donc monté ce dernier dans un boîtier USB3 externe sur une machine Linux Mint. Voici ce que montre "Disks" et la commande "fdisk -l" 5 Partitions (/dev/sdb1 à 5) Le disque est sain, un secteur endommagé Contenu: Linux RAID Member Type: Microsoft basic data !!!???… Question: comme il semble illusoire de pouvoir redémarrer sainement mon TS-131 avec ce WD, comment puis-je procéder pour tenter de récupérer tout ou partie de mes données depuis une machine Linux? Merci, @+, M@ttew
  5. Cible Iscsi Hors Ligne

    Aucune honte, en effet... Je découvre l'utilisation des cibles iSCSi sur mon 119P+ en vue de m'en servir pour installer mes différentes distributions de mes Raspberry Pi, et comme vous, j'ai galéré un moment avant de trouver le moyen de passer "En Ligne"... N'y connaissant rien à cette technologie, je ne voyais pas trop le rapport entre "Autoriser maintenance port 3260" et le mode "Hors Ligne" de la cible! J'ai finalement coché cette case au hasard et comme par magie, ma "Framboise" a soudain réussi à démarrer l'installation de sa distribution sur la cible... Donc, un grand merci à tous de faire partager votre retour d'expérience (que j'aurai pu consulter avant de perdre du temps...) @+, M@ttew
  6. Super, maintenant tout fonctionne grâce à vos conseils. Je poste ici le script déclencheur définitif qui va gérer les différents cas, à savoir: Start, Stop, Reboot, Others [/share/HDA_DATA/.qpkg/launch_pioff] # cat launch_pioff.sh #!/bin/sh USER="pi" SERVER="192.168.1.31" SHELL=/bin/bash CHEMIN="/share/HDA_DATA/.qpkg/launch_pioff" case "$1" in start) #On ne fait rien en cas de démarrage du NAS ;; stop) #On execute l'extinction du RPi+ a l'arret du NAS #Copier l'ancien fichier log avant creation du nouveau /bin/cp $CHEMIN/log/LastPiOff.log $CHEMIN/log/tmp.log #Copier contenu de pioff et le transferer au shell du RPi+ via ssh et recuperer le contenu dans le log LastPiOff #ssh -p $PORT $USER@$SERVER bash < $CHEMIN/pioff.sh /bin/cat $CHEMIN/pioff.sh | /usr/bin/ssh $USER@$SERVER $SHELL > $CHEMIN/log/LastPiOff.log 2>&1 #Copier tmp a la fin de LastPiOff /bin/cat $CHEMIN/log/tmp.log >> $CHEMIN/log/LastPiOff.log #Effacer tmp et attendre 30 sec pour laisser du temps au RPi+ pour s'arreter /bin/rm $CHEMIN/log/tmp.log sleep 30 ;; restart) #On ne fait rien en cas de Reboot du NAS #En effet, si le RPi+ fonctionne sans être sollicité, le volume NFS sur lequel il tourne peut disparaitre le temps d'un Reboot... ;; *) #On ne fait rien dans tous les autres cas echo "Je suis le cas où il ne se passe jamais rien..." ;; esac exit 0 J'ai ajouté une temporisation de 30 sec pour permettre l'extinction propre du RPi+ avant la disparition du volume NFS partagé /share/HDA_DATA/raspberry utilisé pour hébergé son RootFS. Le script déclenché qui ordonne l'extinction du RPi+ (classique, en fait...) [~] # cat /share/HDA_DATA/.qpkg/launch_pioff/pioff.sh #!/bin/sh #Creation variable date DATE=$(date +"%Y_%m_%d_%Hh%Mm%Ss") #Detection du compte utilisateur COMPTE=$(whoami) echo $DATE" <<>> Raspberry Pi has been shutdown by '"$COMPTE"' user from QNAP NAS TS-119P+" sudo shutdown -h now exit Les différents liens symboliques créés grâce à la modification du fichier /etc/config/qpkg.conf [/etc] # ls -la config/qpkg.conf -rw-r--r-- 1 admin administ 1641 Jan 5 14:38 config/qpkg.conf [/etc] # cat config/qpkg.conf ... [launch_pioff] Name = launch_pioff Version = 1.0 Author = M@ttew Date = 2015-01-05 Shell = /share/HDA_DATA/.qpkg/launch_pioff/launch_pioff.sh Install_Path = /share/HDA_DATA/.qpkg/launch_pioff Enable = TRUE [/etc] # ls -la init.d drwxr-xr-x 2 admin administ 4096 Jan 5 14:37 ./ drwxr-xr-x 23 admin administ 2048 Jan 5 15:02 ../ -rwxr-xr-x 1 admin administ 37184 Oct 31 20:21 ImRd.sh* ... lrwxrwxrwx 1 admin administ 50 Jan 5 14:37 launch_pioff.sh -> /share/HDA_DATA/.qpkg/launch_pioff/launch_pioff.sh* ... lrwxrwxrwx 1 admin administ 44 Jan 5 10:35 mtp_run.sh -> /mnt/ext/opt/mtpBinary/etc/init.d/mtp_run.sh* ... lrwxrwxrwx 1 admin administ 46 Jan 5 14:37 phpMyAdmin.sh -> /share/HDA_DATA/.qpkg/phpMyAdmin/phpMyAdmin.sh* ... lrwxrwxrwx 1 admin administ 52 Jan 5 14:37 qpkg_musics.sh -> /mnt/HDA_ROOT/update_pkg/MusicStation/qpkg_musics.sh* ... -rwxr-xr-x 1 admin administ 19093 Jul 9 08:21 wireless_modules.sh* [/etc] # ls -la rcS.d/ drwxrwxr-x 2 admin administ 1024 Jan 5 14:37 ./ drwxr-xr-x 23 admin administ 2048 Jan 5 14:48 ../ lrwxrwxrwx 1 admin administ 52 Jan 5 14:37 QS100MusicStation -> /mnt/HDA_ROOT/update_pkg/MusicStation/qpkg_musics.sh* lrwxrwxrwx 1 admin administ 18 Jan 5 14:37 QS102DownloadStation -> /etc/init.d/btd.sh* lrwxrwxrwx 1 admin administ 46 Jan 5 14:37 QS103phpMyAdmin -> /share/HDA_DATA/.qpkg/phpMyAdmin/phpMyAdmin.sh* lrwxrwxrwx 1 admin administ 50 Jan 5 14:37 QS104launch_pioff -> /share/HDA_DATA/.qpkg/launch_pioff/launch_pioff.sh* lrwxrwxrwx 1 admin administ 17 Oct 31 20:47 S55urandom -> ../init.d/urandom* ... lrwxrwxrwx 1 admin administ 22 Oct 31 20:47 S99z_antivirus -> ../init.d/antivirus.sh* [/etc] # ls -la rcK.d/ drwxrwxr-x 2 admin administ 1024 Jan 5 14:38 ./ drwxr-xr-x 23 admin administ 2048 Jan 5 14:46 ../ lrwxrwxrwx 1 admin administ 17 Oct 31 20:47 K01ldap -> ../init.d/ldap.sh* ... lrwxrwxrwx 1 admin administ 22 Oct 31 20:47 K80init_disk -> ../init.d/init_disk.sh* lrwxrwxrwx 1 admin administ 50 Jan 5 14:37 QK100launch_pioff -> /share/HDA_DATA/.qpkg/launch_pioff/launch_pioff.sh* lrwxrwxrwx 1 admin administ 21 Oct 31 20:47 QK101opentftp -> ../init.d/opentftp.sh* lrwxrwxrwx 1 admin administ 46 Jan 5 14:37 QK101phpMyAdmin -> /share/HDA_DATA/.qpkg/phpMyAdmin/phpMyAdmin.sh* lrwxrwxrwx 1 admin administ 18 Jan 5 14:37 QK102DownloadStation -> /etc/init.d/btd.sh* lrwxrwxrwx 1 admin administ 52 Jan 5 14:37 QK104MusicStation -> /mnt/HDA_ROOT/update_pkg/MusicStation/qpkg_musics.sh* lrwxrwxrwx 1 admin administ 25 Oct 31 20:47 QK107Symform -> ../init.d/init_symform.sh* Remarque: On voit bien que mon script (en dernière position dans le fichier qpkg.conf) est lancé en dernier QS104 au démarrage et lancé en premier QK100 à l'extinction du système, ce qui est cohérent (dernier démarré, premier stoppé => notion de priorité des services j'imagine...) Encore une fois, votre pédagogie est excellente en ne donnant que quelques pistes plutôt que d'avoir un script tout fait auquel on ne comprend rien du tout! A très bientôt, car j'imagine que je ne vais pas m'arrêter là?!... M@ttew
  7. Merci, je suis arrivé au même document sur le Wiki du QNAP et je suis en train d'adapter mon script avec la méthode des FakeQPKG. # cat /etc/config/qpkg.conf ... ... [launch_pioff] Name = launch_pioff Version = 0.1 Author = M@ttew Date = 2015-01-05 Shell = /share/HDA_DATA/.qpkg/launch_pioff/launch_pioff.sh Install_Path = /share/HDA_DATA/.qpkg/launch_pioff Enable = TRUE Petite question: pour cat, rm et cp, j'utilise bien /bin/cat, /bin/rm, /bin/cp mais je n'ai pas trouvé le chemin complet pour ssh, /bin/ssh n'existe pas?!... #!/bin/sh USER="pi" SERVER="192.168.1.31" shell=/bin/bash #Copier l'ancien fichier log avant creation du nouveau /bin/cp /share/HDA_DATA/.qpkg/launch_pioff/log/LastPiOff.log /share/HDA_DATA/.qpkg/launch_pioff/log/tmp.log #ssh -p $PORT $USER@$SERVER bash < /share/HDA_DATA/.qpkg/launch_pioff/pioff.sh /bin/cat /share/HDA_DATA/.qpkg/launch_pioff/pioff.sh | ssh $USER@$SERVER $shell > /share/HDA_DATA/.qpkg/launch_pioff/log/LastPiOff.log /bin/cat /share/HDA_DATA/.qpkg/launch_pioff/log/tmp.log >> /share/HDA_DATA/.qpkg/launch_pioff/log/LastPiOff.log /bin/rm /share/HDA_DATA/.qpkg/launch_pioff/log/tmp.log exit Enfin, sachant que je souhaite stopper le RPi+ uniquement à l'extinction du NAS et ne rien faire au démarrage de ce dernier, comment empêcher la création du lien automatique en rcS.d ? J'imagine que c'est inévitable et qu'il faut créer une condition d'exécution dans le script uniquement dans le cas de l'extinction, non?!...
  8. Bonjour, Merci pour votre rapidité! Pour commencer, j'ai cherché _ en vain _ sur ce forum et n'est pas trouvé mon bonheur, donc preneur du (ou des) fils de discussion s'y rapportant. Se faisant, une recherche sur Google (en l'occurrence, un autre moteur, étant réfractaire aux droïds...) m'a envoyé sur le site que je mentionne dans mon 1er post. La méthode semblait efficace, sachant qu'au départ, j'avais jeté un oeil sur les "runlevels" hélas non utilisés par le Linux embarqué des QNAP à l'inverse d'une Debian classique. Donc, j'ai voulu tout simplement transposer cette méthode à ma situation. Je suis débutant en script et totalement novice en QPKG. Et j'ignorais justement que /etc se trouvait en RAM avec les conséquences évoquées (du coup, je ne comprends pas bien comment il réussit à faire ce qu'il dit sur son post?!...) Idem quant à la description de la section QPKG. Voici le script que je souhaite lancer à l'extinction du NAS: launch_pioff.sh #!/bin/sh USER="pi" SERVER="192.168.1.31" shell=/bin/bash #Copier l'ancien fichier log avant creation du nouveau cp /share/HDA_DATA/homes/admin/log/LastPiOff.log /share/HDA_DATA/homes/admin/log/tmp.log #ssh -p $PORT $USER@$SERVER bash < /share/HDA_DATA/homes/admin/scripts/pioff.sh cat /share/HDA_DATA/homes/admin/scripts/pioff.sh | ssh $USER@$SERVER $shell > /share/HDA_DATA/homes/admin/log/LastPiOff.log cat /share/HDA_DATA/homes/admin/log/tmp.log >> /share/HDA_DATA/homes/admin/log/LastPiOff.log rm /share/HDA_DATA/homes/admin/log/tmp.log cp /share/HDA_DATA/homes/admin/log/LastPiOff.log /share/HDA_DATA/Web/logs/pioff exit Et celui déclenché par le NAS pour éteindre le RPi+: pioff.sh #!/bin/sh sudo shutdown -h now #Creation variable date DATE=$(date +"%Y_%m_%d_%Hh%Mm%Ss") #Detection du compte utilisateur COMPTE=$(whoami) echo $DATE" <<>> Raspberry Pi has been shutdown by '"$COMPTE"' user from QNAP NAS TS-119P+" exit Et une saisie de mon dossier hébergeant ces scripts: [/share/HDA_DATA/homes/admin/scripts] # ls -la drwxr-xr-x 3 admin administ 4096 Jan 4 16:35 ./ drwxrwxrwx 7 admin administ 4096 Dec 29 17:45 ../ drwxrwxrwx 2 admin administ 4096 Dec 17 16:20 .upload_cache/ -r-x------ 1 admin administ 211 Dec 13 15:31 horodatage.sh* -r-x------ 1 admin administ 638 Jan 4 16:30 launch_pioff.sh* -r-x------ 1 admin administ 241 Jan 4 16:35 pioff.sh* -r-x------ 1 admin administ 1366 Dec 15 14:56 updatepydio.sh* Comme précisé dans le post initial, le lancement du script: # launch_pioff.sh depuis le terminal s'exécute sans soucis et le RPi+ s'éteint correctement. Reste donc à trouver le moyen d'interpréter ces 2 scripts dans la procédure d'extinction normale du QNAP. Merci de me consacrer du temps, Cordialement, M@ttew
  9. Bonjour à tous et Bonne Année... Je souhaite exécuter un script à l'extinction et/ou avant redémarrage de mon NAS. En effet, celui-ci possède un partage NFS dans /share/HDA_DATA/raspberry destiné à héberger le RootFS de ma Framboise... afin d'éviter l'utilisation intensive et corruptible de la carte SD de cette dernière. Par conséquent, il me faut impérativement ordonner l'extinction du Raspberry Pi+ avant que le NAS ne s'éteigne, sinon je ne fais que reporter le problème. J'ai donc tout naturellement créé un script "launch_pioff.sh" qui exécute la commande "sudo shutdown -h now" via ssh sur l'IP de RPi+ et l'aide de clés privés/publiques. Le lancement manuel du script est fonctionnel et conforme à mes attentes. Il ne me reste plus qu'à trouver le moyen de le faire exécuter par le système lors de son extinction, et là, la seule documentation trouvée pour le QNAP se trouve sur ce site. En modifiant le fichier suivant: /etc/config/qpkg.conf J'y ai ajouté ceci: [MyPackage] Shell = /share/HDA_DATA/homes/admin/scripts/launch_pioff.sh Or selon l'auteur, le redémarrage du NAS devrait créer les liens symboliques suivants: /etc/init.d/launch_pioff.sh -> /share/HDA_DATA/homes/admin/scripts/launch_pioff.sh /etc/rcS.d/QSxxxlaunch_pioff.sh -> /share/HDA_DATA/homes/admin/scripts/launch_pioff.sh /etc/rcK_init.d/QKxxxlaunch_pioff.sh -> /share/HDA_DATA/homes/admin/scripts/launch_pioff.sh où aux vues du listing suivant, xxx devrait être égal à 104 chez moi... [/etc/rcK.d] # ll … lrwxrwxrwx 1 admin administ 46 Jan 4 17:44 QK100phpMyAdmin -> /share/HDA_DATA/.qpkg/phpMyAdmin/phpMyAdmin.sh* lrwxrwxrwx 1 admin administ 18 Jan 4 17:44 QK101DownloadStation -> /etc/init.d/btd.sh* lrwxrwxrwx 1 admin administ 21 Oct 31 20:47 QK101opentftp -> ../init.d/opentftp.sh* lrwxrwxrwx 1 admin administ 52 Jan 4 17:44 QK103MusicStation -> /mnt/HDA_ROOT/update_pkg/MusicStation/qpkg_musics.sh* lrwxrwxrwx 1 admin administ 25 Oct 31 20:47 QK107Symform -> ../init.d/init_symform.sh* [/etc/rcK.d] # ll /etc/rcK_init.d/ drwxr-xr-x 2 admin administ 1.0k Nov 21 2006 ./ drwxr-xr-x 23 admin administ 2.0k Jan 4 22:29 ../ Hélas, rien de tout cela, et le redémarrage n'a rien créé du tout. Du coup, j'ai moi-même créé les liens symboliques en question et ordonné le redémarrage du système. Comme il fallait s'y attendre, le script ne s'est pas exécuté (j'ai un fichier de log qui s'incrémente sur le NAS à chaque exécution du script et le RPi+ ne s'est pas arrêté...) et "étrangement", les liens symboliques ont disparu après l'opération, comme s'ils n'avaient jamais existé?!... Je suis donc au point mort, pourtant la méthode me paraissait intéressante et plausible. Le seul doute réside dans le fait qu'elle date de 2008 (6 ans déjà), et le firmware du NAS en question (un TS-209 II) n'est pas précisé mais doit être bien différent de celui d'aujourd'hui sur mon TS-119 P+ Voilà, si quelqu'un sait comment exécuter un script perso à l'extinction, je suis preneur... Merci à tous, @+, M@ttew
  10. Ajaxplorer Vers Pydio - Mises À Jour

    J'entends bien, et je suis conscient du problème... Il n'y a qu'à regarder la news concernant SynoLocker publiée ce matin pour mieux appréhender les risques potentiels! Cela dit, je ne veux pas risquer de perdre le fonctionnement de mon application php sans prendre de précautions! J'ai donc décidé d'acquérir un second NAS, le modèle TS-121 avec un HD de 3To afin de migrer mes données sur ce nouveau modèle, puis tenter d'installer proprement mon application php dessus, et une fois fonctionnelle, je ferai un update du TS-119 avec _ je pense _ un RAZ des données du HD 2To qui occasionne des erreurs comme décrites dans ce Wait & See... @+, M@ttew
  11. Ajaxplorer Vers Pydio - Mises À Jour

    Bonjour, Merci pour le debrief... Voici ce que me donne la console... Pour info, je suis encore en 3.8.1 Build 20121205. En effet, j'utilise le serveur Web avec une application développée en php, et certaines fonctionnalités que vous m'avez aidé à mettre en place il y a 1an et demi (cf: ). Or je redoute que le passage du firmware en 4.1.0 n'occasionne des soucis de fonctionnement de cette application, et je ne me sens pas trop capable de reprendre l'installation complète de la chose... Concernant les QPKG, j'utilise le minimum: Owncloud est désactivé, et va dégager à terme, car Pydio me convient mieux et est bien plus léger. Quant à Squid, l'usage souhaité (utiliser ce proxy depuis le boulot) n'est plus d'actualité, car impossible de l'atteindre (l'accès au Net est extrêmement cloisonné…) Reste donc phpmyadmin et optware dans mon cas. En revanche, je remarque que /.eaccelerator.tmp consomme 49% des 32Mo chez moi alors qu'il est à 0% chez vous?!... Je vais surveiller le fonctionnement à compter de ce redémarrage. Pour le moment, cela fonctionne. @+, M@ttew
  12. Ajaxplorer Vers Pydio - Mises À Jour

    Bonjour, Merci pour la réponse. Problème résolu, car aucun rapport avec ma question en fait... Je commence à avoir de sérieux problèmes avec mon NAS, je pense à une défaillance du disque dur. A priori, la décompression du zip plantait car le NAS ne parvenait pas à écrire dans le dossier /tmp de téléchargement de l'archive. Etrange car il avait réussi à le faire avec les 3 précédentes màj... Bref, j'ai effectué un redémarrage du serveur ce matin (entretemps, j'ai eu un certain nombre d'erreurs sans rapport avec cette màj m'invitant à redémarrer…), et dans la foulée, la màj online de Pydio s'est déroulée sans soucis! Pour répondre à la question, j'ai utilisé le "ajaxplorer5_5.0.qpkg" trouvé sur ce forum. @+, M@ttew
  13. Ajaxplorer Vers Pydio - Mises À Jour

    Bonjour à tous, Je viens de découvrir AjaXplorer et j'avoue être bluffé par ce système de cloud personnel. J'ai procédé comme précisé par l'installation de la version 5 trouvée sur ce forum. Tout s'est bien déroulé. Puis, j'ai exécuté les mises à jour recommandées suivantes au sein même de l'application: ajaxplorer-core-upgrade-5.0.1-5.0.2 ajaxplorer-core-upgrade-5.0.2-5.0.3 ajaxplorer-core-upgrade-5.0.3-5.0.4 A l'issue, on se retrouve sur la première version dénommée Pydio désormais. Là, le serveur m'invite à effectuer les mises à jour suivantes: pydio-core-upgrade-5.0.4-5.2.0 pydio-core-upgrade-5.2.0-5.2.1 pydio-core-upgrade-5.2.1-5.2.2 pydio-core-upgrade-5.2.2-5.2.3 Je m'exécute à nouveau. Hélas, le serveur m'informe qu'il n'a pas réussi à décompresser l'archive "pydio-core-upgrade-5.0.4-5.2.0.zip" car celle-ci semble corrompue... Et j'en suis là. J'ai bien trouvé le dossier de stockage des fichiers de màj, l'archive est bien présente, mais je ne sais pas comment faire pour forcer l'opération. En cherchant sur le Net, j'ai trouvé le lien de téléchargement de la mise à jour en question: http://sourceforge.net/projects/ajaxplorer/files/pydio/stable-channel/5.2.0/pydio-core-upgrade-5.0.4-5.2.0.zip/download Seulement, je ne sais pas comment faire pour relancer la procédure de mise à jour avec cette version du fichier?!... Voilà, si quelqu'un a une idée, elle sera la bienvenue. @+, M@ttew
  14. Extinction Inopinée Du Nas

    Bonjour, Il y a 3 jours (donc le 12), j'ai noté un fonctionnement anormal du disque externe (eSATADisk1) comme s'il tournait dans le vide, se mettait en pause, puis se relançait sans raison. Mes doutes furent confirmés lorsque j'ai reçu cette notification: [eSATADisk1] Device removed. Du coup, j'ai décidé d'arrêter le disque externe. Laissant alors fonctionner le NAS seul pendant 48h, je n'ai plus eu d'extinction inopinée. J'ai donc décidé de démonter le disque externe et de le tester dans un autre boitier réputé fiable. Etant sous OSX, j'ai dû en passer par l'installation des drivers compatibles ext2,3 et 4 pour accéder à la partition du DD, mais après ces quelques manipulations, j'ai constaté que le disque semblait en état. J'ai entrepris un stress test en lisant une vidéo .mkv de 16Go sous VLC et en copiant un dossier de 58Go en même temps sur le disque. Pas de problème, pas de déconnexion intempestive, j'en conclu donc que le boitier est défectueux! Il s'agit d'un boitier acheté en septembre 2010 chez Macway (pourtant réputé d'habitude) et qui a rapidement présenté des signes d'instabilité en eSATA et en USB2 dans les mois qui suivirent l'achat, ainsi que le second boitier mentionné sur l'image... J'ai donc demandé une réparation des 2 boitiers, et depuis, tout semblait fonctionner correctement jusqu'à la semaine dernière... Ainsi, le boitier est de nouveau instable, et aux vues de ces presque 4 années, il va rejoindre le cimetière des objets polluants obsolètes!!! J'ai donc re-connecté le disque dur dans son nouveau boitier au NAS, et depuis 24h, tout fonctionne correctement, avec divers stress tests du HD. Bilan: Le NAS n'a pas dû apprécier les déconnexions-reconnexions du HD en eSata et a fini par planter en forçant l'extinction du système... Le disque externe était donc la source du problème. En revanche, le log du NAS indique à chaque redémarrage : [single Disk Volume: Drive 1] The file system is not clean. It is suggested that you run "check disk". Or le test du disque m'a donné: [Drive 1] Bad Blocks Scan completed. 257 bad block(s) found. Le disque interne du NAS est un WD Red 2 To (pourtant recommandé pour ce genre de machine…) de 2 ans à peine avec peu de sollicitations au demeurant. Je m'étonne d'un si grand nombre de secteurs défectueux. Que faut-il faire? Changer le disque en préventif? Est-ce réparable au sein du système? Faut-il ré-installer le firmware, effacer le disque puis tout recopier? Je pense faire l'acquisition d'un second NAS identique (modèle TS-121) avec un HD de 3To. Que penser du WD Red 3To? Y a-t'il un modèle concurrent réputé? Merci, @+, Onyxsmith
  15. Extinction Inopinée Du Nas

    Bonjour, Merci pour votre réponse. Je reprends les points à la suite: 1 J'ai commencé par là, ce qui explique les évènements suivant: "1099","Information","2014-07-06","09:08:29","admin","192.168.1.11","---","[Power Management] System will be restart now." "1104","Information","2014-07-06","09:27:13","admin","192.168.1.11","---","[Power Management] System will be shutdown now." 2 Je n'ai pas encore testé l'arrêt des QPKG, mais cette nuit, j'ai fait 2 nouveaux tests: "1156","Information","2014-07-11","04:38:35","System","127.0.0.1","localhost","[eSATADisk1] Device removed." "1155","Warning","2014-07-11","04:27:56","System","127.0.0.1","localhost","[Drive 1] Bad Blocks Scan completed. 257 bad block(s) found." "1154","Information","2014-07-11","01:06:42","System","127.0.0.1","localhost","[eSATADisk1] Device detected. The file system is ext4." "1153","Information","2014-07-11","01:04:55","System","127.0.0.1","localhost","[eSATADisk1] Device removed." "1152","Information","2014-07-11","00:42:20","System","127.0.0.1","localhost","[eSATADisk1] Device detected. The file system is ext4." "1151","Information","2014-07-11","00:41:55","System","127.0.0.1","localhost","[eSATADisk1] Device removed." "1150","Information","2014-07-11","00:39:34","System","127.0.0.1","localhost","[eSATADisk1] Device detected. The file system is ext4." "1149","Information","2014-07-10","23:04:43","System","127.0.0.1","localhost","[eSATADisk1] Device removed." "1148","Information","2014-07-10","22:52:57","System","127.0.0.1","localhost","[Drive 1] Start scanning bad blocks." "1147","Information","2014-07-10","22:49:02","System","127.0.0.1","localhost","[Media Library] Media Library Server started." "1146","Information","2014-07-10","22:47:25","System","127.0.0.1","localhost","[single Disk Volume: Drive 1] Examination completed." "1145","Information","2014-07-10","22:40:55","System","127.0.0.1","localhost","[single Disk Volume: Drive 1] Start examination." Le système de fichier semble ok, mais grosse mauvaise surprise pour les "bad blocks"! Et pendant le scan, alors que le disque eSATA n'était pas sollicité (la nuit, hébergeant une vidéothèque sans personne connecté dessus…), il s'est déconnecté 4 fois! Et d'ailleurs, ce matin, il est toujours dans les choux! 3 Comme dit précédemment, les accès ne se font que par NFS, AFP ou WebDAV depuis mon réseau local via une interface XBMC sur Mac, iPad ou Androïd afin de visionner des films. Donc, usage très restreint du disque externe. 4 Concernant Apache, je faisais une démonstration à l'utilisateur "Keven" d'un site Web hébergé sur le NAS dans le volume /Web du Lecteur 1 depuis son Mac, et là, la page html s'affichait, mais le code PHP/MySQL ne s'interprétait pas (les requêtes restaient vides!) J'ai donc cherché à comprendre pourquoi, et en fouillant dans l'interface admin (avant d'avoir vérifié que ça plantait aussi sur mes machines), j'ai donc essayé de changer les droits d'accès de l'utilisateur Keven _ sans succès bien sûr. Finalement, je réalise que mes machines échouent aussi et je percute en relançant le server MySQL planté pour une raison inconnue?!... Maintenant, la relance d'Apache par System et l'hôte local, je ne comprends pas non plus?!... "1120","Information","2014-07-07","23:21:24","admin","192.168.1.129","---","[MySQL Server] Started successfully." "1119","Information","2014-07-07","23:06:29","admin","192.168.1.129","---","[users] User [Keven]'s shared folder access rights changed." "1118","Information","2014-07-07","23:06:25","admin","192.168.1.129","---","[users] User [Keven]'s shared folder access rights changed." "1117","Information","2014-07-07","23:04:34","admin","192.168.1.129","---","[users] User [Keven]'s shared folder access rights changed." "1116","Warning","2014-07-07","22:35:46","System","127.0.0.1","localhost","Re-launch process [apache]." Pour l'update du firmware avec la même version, que se passe-t'il au niveau des disques? Sont-ils effacés? Et pour les QPKG installés? J'ai Optware et phpMyAdmin installés dessus. En gros, je fais tourner 3 sites web hébergeant des bdd personnelles dont l'une d'entre elles est un peu particulière puisqu'elle a des droits "admin" sur le système de fichier, cf ce post: La mise en place de la configuration ayant été plus que laborieuse aux vues de mes faibles connaissances, j'ai donc depuis évité tout upgrade du firmware, le système étant stable jusqu'à la semaine dernière... Dois-je tout re-configurer en cas d'upgrade même si je restaure la même version? Concernant le support, existe-t'il en français, car cela risque d'être tendu de m'expliquer en anglais?!... Cordialement, @+, Onyxsmith
×