kralisec

Bonjour, C'est présenté comme si il suffit de s'inscrire pour y avoir droit (on a le droit de rêver ^^) et 3 clics + loin on se retrouve à commander une extension de garantie ... 😞

Bonjour, Côté Syno : DSM 7.0.1 à jour, Panneau de configuration, Services de fichiers, Paramètres avancés (voir attachement) Côté iphone : ios 15.3, aller dans fichier, les 3 petits points puis "Se connecter au serveur" Serveur : 1.2.3.4 (adresse IP de votre serveur) puis "se connecter" (vous pouvez mettre son nom si la résolution le permet) cocher "Utilisateur référencé" puis ajouter Nom et "Mot de passe" Cela fonctionne comme cela depuis pas mal de temps (depuis que j'ai découvert par hasard que je pouvais connecter le syno depuis la tablette : plus besoin de passer par icloud pour échanger un fichier) Depuis hier impossible de se connecter : sur ipad fichiers donne toujours le message d'erreur (ipados 15.3) "Impossible de terminer l'opération, car une erreur inattendue est survenue" même en smb 1.0 Après une recherche sur google qui m'amène ici et avoir changé chaque paramètre partout sans résultat ^^ je vois que je n'ai pas ce problème avec l'iphone (ios 15.3), je reviens au paramétrage de départ (celui au-dessus), je retente avec l'ipad : toujours l'erreur, je redémarre l'ipad et bingo : maintenant c'est tout bon !!! (au 2ème essai)

Bonsoir, Si il est pas trop tard: est-ce que le modèle DS411J est le même ?

Je l'utilise de manière très basique: serveur de fichiers et dlna, j'ai pas vu de différence.

Yep ... Je viens de réactiver le module Media Server: la charge reste à 2.5 Perso je suis sévèrement impressionné par le travail de Synology : continuer à fournir des mises à jours 6 ans après la sortie du produit, on aurait pu croire que avec 128Mo de mémoire le matériel serait poussé vers la sortie, mais non: il est encore la et bien la !! Merci Synology, j'ai fait un choix et je continue de le recommander autours de moi.

Un "bon" technicien va toujours lire la doc quand il est dans les emm... ^^ (ironie) ce sera pour les autres qui ne lisent pas comme moi :)

DS-411J : après passage en 6.1 ajout de 2 packages sans me demander mon avis ... - Universal Search - File Station Avec mes 128Mo de mémoire c'est une idée à suivre: j'ai fait un stop sur le package Media Server dans le doute j'ai laissé actif: Perl et Php 5.5 Après reboot le charge est monté brièvement à 49 avant de redescendre pour se stabiliser à 9 et maintenant 0.5 Je lui ai pas demandé moi de faire un nouveau truc d'indexation de mon disque, le pire c'est que c'est pas possible de désactiver / stop / désinstaller depuis l'interface ... Je vais fouiner si c'est possible de virer ce truc sans que cela me revienne en pleine poire ^^

J'ai configuré un /root/.ssh/authorized_keys et je me suis même pas aperçu de la restriction ^^ Merci pour l'info, Laurent.

Bonjour, Après avoir reçu 4 mails de mise à jour automatique DSM6 autours de moi j'ai mis à jour aussi ... pour le moment tout est ok mon utilisation est très très basique: share + dlna, pas d'accès extérieur, pas de script, rien de rien, package perl + media server mis à jour, hardware DS 411J + DD 2To wd green. a+, Laurent.

Un autre essai de copie avec --bwlimit=1000 Mem: 91856K used, 26608K free, 0K shrd, 1464K buff, 25068K cached CPU: 0.0% usr 0.1% sys 0.0% nic 99.6% idle 0.1% io 0.0% irq 0.0% sirq Load average: 0.63 0.24 0.09 1/233 28796 le load augmente et baisse comme par vague, mais chaque nouveau pic va plus loin que le précédent, hier j'ai eu 0,28, la j'ai vu 0,45 puis 0,75 => ctrl-z à ce moment (c'était la dernière valeur avant le crash avec --bwlimit=5000) après reprise du job par fg la variation revient progressivement, 2mn pour repasser à 0,30 baisser à 0,10 Mem: 93488K used, 24976K free, 0K shrd, 1632K buff, 27624K cached CPU: 0.1% usr 0.1% sys 0.0% nic 99.2% idle 0.3% io 0.0% irq 0.0% sirq Load average: 0.14 0.14 0.09 1/233 29015 Mem: 101320K used, 17144K free, 0K shrd, 1652K buff, 29400K cached CPU: 0.0% usr 1.3% sys 0.0% nic 97.4% idle 0.3% io 0.0% irq 0.7% sirq Load average: 0.10 0.13 0.09 1/232 29020 Bref, la charge est la bonne piste, une théorie à 2 balle: le système de cryptage est + gourmand en opération mathématique que les précédentes version, le cpu J ne suit pas :( a+, Laurent.

@daffy: merci pour ton retour. @Fenrir: pour l'idée que le disque presque plein coûte cher en cpu, le fichier a été créé en un seul block continue, c'est pas une taille dynamique, je pense pas que cela soit un critère. Je viens de faire un rsync pour les valeurs de top: au repos: Mem: 96624K used, 21840K free, 0K shrd, 1624K buff, 32976K cached CPU: 0.1% usr 0.1% sys 0.0% nic 99.6% idle 0.0% io 0.0% irq 0.0% sirq Load average: 0.02 0.06 0.01 1/233 30402 avec --bwlimit=1000 => pas de crash (fichier 400Mo) Mem: 89660K used, 28804K free, 0K shrd, 1600K buff, 25740K cached CPU: 0.0% usr 0.3% sys 0.0% nic 99.0% idle 0.5% io 0.0% irq 0.0% sirq Load average: 0.28 0.13 0.03 1/234 30446 avec --bwlimit=5000 => crash après 40s de copie, dernière valeur (fichier 400Mo) Mem: 109148K used, 9316K free, 0K shrd, 1480K buff, 29256K cached CPU: 0.1% usr 11.8% sys 0.0% nic 17.0% idle 64.9% io 0.3% irq 5.5% sirq Load average: 0.78 0.28 0.09 3/234 30474 Le load monte vite ... Valeurs en reconstruction du raid (pour comparaison, c'est censé être une tâche "lourde") Mem: 97716K used, 20748K free, 0K shrd, 1772K buff, 21784K cached CPU: 0.3% usr 0.5% sys 0.0% nic 76.3% idle 22.6% io 0.0% irq 0.0% sirq Load average: 0.03 0.23 0.64 2/234 8393 Cela fait qque temps que j'avais pas écrit aussi je ne sais pas à quand cela remonte, mais le problème ne s'est jamais présenté avec un DSM 4 par exemple. Un crash de cette violence c'est tout de même étonnant, d'autres idées ? a+, Laurent.

Bonsoir, J'espère croiser par ici un ou plusieurs curieux qui voudront bien me suivre avec un problème que j'ai rencontré déjà 4 fois, en gros: crash total du syno au moment de l'écriture (environ 10Mo/s) sur un lun iscsi avec une couche crypto ... Le linux se porte bien lui puisque une fois le syno revenue à la vie il tenter de continuer d'écrire jusqu'une prochain reboot. Le crash est avéré: plus de son / plus d'images (i.e.: plus de ping et un uptime de 2mn au ssh suivamt) pour le moment j'en suis à 4 crash, le seul truc qui semble aider c'est d'ajouter un --bwlimit=1000 dans la commande rsync une copie directement sur le volume du nas fonctionne sans problème (par smb, rien à voir avec le lun) et pour info: le lun a été ajouté sur l'espace disque du volume du syno (il n'y pas sa partition dédié) Je mets ci-dessous un max d'infos technique qui peuvent être lié au problème DS-411J - 3 DD 2To + 1 DD 2.5Go (suite échange défectueux) - système quasi plein: 17Go de libre :( - DSM derniers en date 5.2-5644 - LUN 20Go en Thin Provisionning No Aucun accès externe aussi bien par redirection de port ou quickconnect (en cas de suspicion virus ou autre) utilisation extrèmement basique, packages installés: media server (dlna) et surveillance station (tourne pas) Accès depuis ubuntu 14.04 LTS 64b : - open-iscsi : 2.0.873-3ubuntu9 - crypsetup : 2:1.6.1-1ubuntu1 montage en wifi Intel(R) Dual Band Wireless AC 7260, REV=0x144: vitesse de copie entre 6 et 14Mo/s Comme j'ai qu'1 syno je suis pas terriblement chaud pour continuer à crasher le système, je suppose qu'à force d'insister il va finir par le me faire payer ^^ Mais si qqu'un a des question n'hésitez pas, ce serait déjà un bon départ de savoir si c'est reproductible. a+, Laurent.

Bon ben j'ai trouvé sur un site la solution pour le problème avec rsync (voir + haut): il faut ajouter --rsync-path=/usr/syno/bin/rsync En fait c'est pas un "bug temporaire", c'est une nouvelle façon de faire les choses (question de sécurité si j'ai bien compris) a+, Laurent.

Moi c'est rsync qui ne fonctionne plus, 2 syno en DSM 5.1-5004 Update 2 Permission denied, please try again. rsync: connection unexpectedly closed (0 bytes received so far) [Receiver] rsync error: error in rsync protocol data stream (code 12) at io.c(226) [Receiver=3.1.0] C'est clairement lié à la mise à jour, cela fonctionnait encore hier ... ^^ qqu'un a déjà rencontré ce problème ? a+, Laurent.

Ok, j'ai trouvé la source de mon problème: la ligne video source=”/live/ch01_0″ utilise 2 codages différents pour le caractère " et les 2 ne sont pas bon ... => en gros: la solution est d'effacer entièrement la ligne et de la refaire à la main. Sinon vous pouvez le copier depuis ici: video source="/live/ch01_0" a+, Laurent.