Fenrir

Ce que je veux dire, c'est que ce n'est pas forcement lié à ton installation, mais à un bug connu de Synology. Ça ne semble pas gêner outre mesure mon nas, mais il est peu utilisé (il est allumé 1h par semaine le temps de backuper le nas principal) Au feeling, si c'est juste un problème de séquence de démarrage, ça peut se contourner/réparer facilement. Par contre, si ça touche les logs et que tu en as besoin (entreprise), alors il est important d'y prêter attention Si j'y pense et que j'ai le temps, j'y jetterai un coup d’œil ce weekend

De rien, bon film

Je n'ai pas encore eu le temps d'y regarder de plus près, mais j'ai tout de même 2 éléments de réponse : j'ai le même soucis sur un des mes nas : il est apparu après une réinstallation complète j’avais contacté le support Synology : ils sont déjà au courant du soucis je crois me souvenir que c'est après avoir jouer avec l'archivage des logs

tu peux aussi voir la vitesse dans le moniteur de ressources du syno (disque) pour le lenteur, c'est peut être aussi du aux secteurs défaillants, si le syno doit passer dessus (même sans les lires), ça peut fortement ralentir la lecture

​snmpget, nagios et centreon existent sous Windows, Solarwind ne tourne QUE sous Windows

Il y a souvent un cache (coté OS, pas Syno) Pour faire ton test : reboot ton mac monte un dossier en AFP va dans un sous dossier qui contient beaucoup de fichiers =>si c'est toujours lent pour afficher la listes des fichiers, il y a peut être un soucis sur ton mac (antivirus, indexation, ...) Pour ce qui est de la lenteur d'affichage quand une copie est en cours, ça fait des années que je n'ai plus de mac, donc je ne peux pas te dire si c'est normal ou non (accès concurrents, lock, ...), mais ça ne me semble pas normal.

+1 Ça passe même à 15 secondes au coup d'après. Que l'on fasse une vraie recherche ou que l'on utilise les filtres (messages depuis votre dernière visite/...), le problème est le même. Merci

Installe les 3 paquets que j'ai cité, ils vont automatiquement créer des partages nommés : music photo video Pour commencer, c'est le plus simple, après tu verras à l'usage Si les paquets ne te conviennent pas, tu pourras les désinstaller (ça ne supprime ni les fichiers que tu as copié, ni les partage, donc tu ne risque rien)

regarde déjà si le temps de chargement de la liste des fichiers est aussi lent (c'est très subjectif) puis test avec la copie d'un gros fichier et d'un paquets (plusieurs centaines) de petits fichiers Pour le débit, tu peux regarder dans les widgets du synology

Le pomme+i (ou un truc du genre), c'est à faire sur le point de montage dans ton mac Tu peux parfaitement avoir des dossiers monté en AFP et d'autres en CIFS/SMB en même temps, c'est à toi de choisir quoi monter et comment Si tu utilises afp://... ça sera en afp Si tu utilises cifs://... ça sera en cifs Pour les tests, assure toi de bien les faire en AFP et pas en CIFS : déconnecte tous les lecteurs connecte un partage via afp://ton.nas.... test dans ce partage Puis refais la même chose (1/2/3) mais en cifs et compare avec le même dossier. Si c'est toujours aussi lent, tu peux tester en NFS

Non, je n'ai plus utilisé de mac depuis quelques années, mais tu devrais pouvoir rendre ça automatique Si le partage que vois est apparu après avoir entré apf://nas2013.local/TON_PARTAGE, il ne devrait pas y avoir de doute possible Sinon il y a plusieurs manières de le savoir, le plus simple est de saisir la commande "mount" dans un terminal, ça te dira en quoi c'est monté Je crois me rappeler qu'en faisant pomme+i sur le partage ça donnait cette info Tu peux aussi désactiver (au moins temporairement) les autres services de fichier sur le nas (ça ne supprime rien) Et niveau temps d'accès, ça donne quoi ?

Essaye en AFP ou en NFS, le CIFS présente souvent ce problème sur Mac Active le service de fichier MAC : https://help.synology.com/dsm/?section=DSM&version=5.1&link=AdminCenter%2Ffile_winmacnfs_win.html Puis : https://help.synology.com/dsm/?section=DSM&version=5.1&link=Tutorial%2Fstore_with_mac.html

Bonjour initié Je me suis mal exprimé, ce que je voulais dire c'est : comme il est normal (pour CloudStation) que ces fichiers ne soient pas synchronisés, il est normal qu'il n'indique pas d'erreur s'il ne les synchronise pas. Pour le problème de dates, je suis d'accord avec toi qu'un système de sauvegarde ne doit JAMAIS les modifier. Par contre je ne considère absolument pas CloudStation/Dropbox/Owncloud/Box/OneDrive/... (en fait tous les bidules de synchro bidirectionnelle) comme des systèmes de sauvegarde. Pour ce qui est des dates : si je déplace un fichier d'un endroit (par exemple mon disque local) vers un autre (par exemple un partage du nas), la date de création est conservée. si j'en fait une copie (par exemple de mon disque local vers le nas ou vers un autre dossier de mon disque local), la date de création est heureusement différente de celle de l'original La date de modification elle ne change pas, car c'est un autre type de donnée. Essaye de déplacer un fichier dans le dossier de synchro, la date ne devrait pas changer

qui est connecté, voir le débit, utilisation CPU, RAM et disque dur => tu peux le faire avec des snmpget sur les bons OID, le tout dans un petit script mais en général on fait faire ce genre de chose à un logiciel de surveillance (nagios, centreon, zabbix, solarwind ...) Pour ce qui est d'envoyer les logs par mail, c'est aussi parfaitement faisable en quelques lignes de scripts sur le syno Par contre un truc prêt à l'emploi qui fait tout ça, je ne pense pas que ça existe (surtout pour Windows)

je n'ai pas testé CloudStation depuis un bail, mais certaines des "limitations" que tu indique ne sont pas de son fait : Le dossier ou chemin du fichier contient un des caractères suivants : *: ? / » < > | => cette liste de restriction est celle de Windows, donc même si sur d'autres système ça peut marcher, ils ont probablement fait ce choix pour limiter les problèmes avec les utilisateurs Windows Le type de fichier est un des suivants : .tmp .temp .swp .lnk => en général les fichiers de ce type n'ont pas besoin d'être synchronisés/sauvegardés car il devrait s'agir de fichiers temporaires (tmp/temp), d'échange (swp) ou de raccoucis (lnk), mais de mémoire c'est réglable dans le client Le fichier commence par un des caractères suivants : ._ ~ => même réponse qu'au dessus Le nom de fichier est, ou contient, un des suivants termes : .ds_store desktop.ini @eadir thumbs.db => même raison qu'au dessus Le dossier ou chemin du fichier est plus long que 247 caractères. => limitation Windows (de certains composants Windows pour être précis, dont l'explorateur) Le nom de fichier contient plus de 255 caractères. => limitation Windows Pour ce qui est des dates, en tant que photographe tu ne devrais pas (jamais ?) te servir des dates des fichiers, mais des dates des metadatas, néanmoins le fait que les dates des fichiers soient modifiées est un vrai problème en soit s'il est avéré. Tu n'aurais pas fait une copie de ces fichiers vers le dossier CloudStation, car dans ce cas c'est normal, tu as créé des nouveaux fichiers, un déplacement conserve la date de création, une copie non. Par contre la date de modification ne devrait pas changer.

Si pour toi un NAS n'a pour seule utilité que de visionner tes vidéos sur ta TV, l'achat d'un NAS est superflu, tu peux parfaitement rester en mode "disque externe", par exemple avec XBMC sur RPi. Ça peut faire un (très) bon media center pour pas cher (et tu peux partager les données du RPi avec ton mac en installant un serveur NFS sur le RPi) Maintenant, sans vouloir le moins du monde te pousser à l'achat, les NAS Synology/Qnap (et quelques autres) permettent de faire bien d'autres choses que de stocker des fichiers, contrairement à un disque externe. Je ne vais pas décrire toutes les possibilités, mais il y a vraiment de quoi faire, ce n'est pas du tout comparable à un disque externe (même s'il a une prise réseau). Jette un œil par ici : https://www.synology.com/fr-fr/dsm/live_demo nb : leur site de demo est souvent très lent

+1 Sous Linux on dit couramment "Si ton disque est fragmenté, c'est qu'il est trop petit/plein" Les systèmes de fichiers comme l'ext4 organisent différemment (certains diront intelligemment) les fichiers à la surface du disque. En gros, au lieu de mettre les fichiers les uns à la suite des autres en laissant très peu de place entre (ce qui créé très vite de la fragmentation dès qu'un fichier est modifié), ils laissent beaucoup de place autour, ce qui permet au fichier d'évoluer sans fragmentation, jusqu'à un certain point, si le fichier bouge vraiment beaucoup et/ou si le disque est presque plein (% ou plus), il y a aura tout de même un peu de fragmentation.

Je ne veux pas te donner de faux espoirs, il y a peu de chance que tu récupère tes fichiers (la suite est en blanc sur fond blanc) Si tu as n'as pas écrit sur le disque depuis (en gros que tu as éteint le syno dès que tu as vu ton erreur), tu peux tenter une resto depuis un pc sous Linux, mais c'est du taf et sans aucune garanti de réussite. Pour faire simple : 1-connecte UN des disques sur un PC sous Linux (rien de compliqué) 2-identifie le device concernée (nb : c'est du LVM sur du raid) 3-utilise un soft de restauration (il y en a plein, mais ceux qui marchent bien avec du raid sont généralement assez cher) Si tu arrive bien à monter la partition concernée, tu peux aussi tenter de faire un DD bloc par bloc vers un device "simple" et donc utiliser des softs plus basiques ps : le fond d'écran par défaut des nas devrait être un message écrit en gros, gras, rouge : "Faites des sauvegardes ailleurs que sur ce NAS" (en plus ça leur permettrait de vendre 2 fois plus de nas )

En plus de ce qui est indiqué dans post précédent : ton script ne travail pas dans les sous dossiers (mais peut être que filebot le fait tout seul) tu considère que tous les fichiers sont à traiter si le nom de fichier contient de espaces (ou autre caractère spécial), tu risque d'avoir des surprises (sauf si filebot le gère correctement) tu peux aussi le faire avec find -exec : find /volume1/video/Download/ ( -name @eaDir -prune ) -o -type f ( -name '*.avi' -o -name "*.mkv" ) -exec ls -l {} ; ou avec find + xargs find /volume1/video/Download/ ( -name @eaDir -prune ) -o -type f ( -name '*.avi' -o -name "*.mkv" ) -print0 | xargs -0 ls -l la syntaxe peut paraitre compliquée, mais elle est plus fiable (normalement...) Dans un script ça donnerait un truc du genre : #!/bin/sh #on change le séparateur par défaut (pour traiter les caractères spéciaux) IFS_backup=$IFS IFS=$(echo -en "nb") #boucle pour traiter les fichiers 1 par 1 (en évitant cette #@!!%$ de dossier @eaDir) for FILE in `find /dossier -type f ( -name @eaDir -prune ) -o ( -name '*.avi' -o -name "*.mkv" )` do echo "Lancement d'une commande sur le fichier [$FILE]" echo "Lancement d'une commande sur le fichier [$FILE]" >> tonfichier.log done IFS=$IFS_backup exit 0 mais encore une fois, ça dépend de filebot, s'il travail correctement (gestion des files d'attente, des caractères spéciaux, des sous dossiers, ...), ton script devrait faire le job

en tirant dans toutes les directions j'étais presque certain de tomber juste au moins une fois pour marquer le post en résolu, c'est à toi de le faire (edit ton premier message)

ne stock pas les téléchargement dans un dossier pris en compte par l'indexation dans ton script, fais 2 opérations : renommage déplacement dans un dossier indexé planifie le tout toutes les 1 minutes

je ne pense pas que le "temps réel" soit vraiment nécessaire pour ce type d'usage surtout que dans ce cas tu fais un confiance aveugle à filebot Pour incron, il est possible de le compiler, mais son intégration avec le système risque d'être assez complexe Je pense qu'il est plus simple de faire une petite tache planifiée qui tourne de temps en temps

Test avec le client Hubic officiel depuis ton pc/mac Si as le même débit (faible), le problème vient probablement de ton FAI ou d'Hubic Si tu as un bon débit, le problème vient probablement du syno J'avais testé vite fait à un moment, je n'ai pas eu l'impression que c'était si lent Normalement il n'y a rien à ouvrir d’Internet vers ton Syno. Sinon, il y a 8bits dans un octet (Byte), ton calcul est correct

oui, ou utiliser le paquet vpn du syno dans tous les cas, règle bien le firewall et l'anti brute force

la notation "standard" (on va dire la plus répandue et la plus reconnue est : Nom sXXeXX Par exemple, la série Synology (fictive) dont le premier épisode est comme souvent en 2 parties : Synology s01e01-1.mkv Synology s01e01-2.mkv Synology s01e02.mkv Synology s01e03.mkv ...