This site uses cookies! Learn More

Ce site utilise des cookies !

En continuant à utiliser ce site, vous vous engagez à nous permettre de stocker des cookies sur votre ordinateur.

 

Si nous utilisons des cookies et retenons des données anonymes, c’est pour nous aider à mieux gérer notre mesure d’audience, aider nos partenaires commerciaux à nous rémunérer et nos partenaires publicitaires à proposer des annonces qui vous correspondent.

 

Grâce à ces cookies, le forum est en mesure de savoir qui écrit un message et utile pour le système d'authentification.

 

En cliquant sur « J'accepte », vous acceptez l'utilisation par NAS-Forum de cookies publicitaires et de mesure d'audience fine.

lordtaki

Membres
  • Compteur de contenus

    380
  • Inscription

  • Dernière visite

  • Jours gagnés

    6

Tout ce qui a été posté par lordtaki

  1. J'ai aussi ce problème lors du téléchargement de fichiers via file station.
  2. fdupes doit être disponible avec une source de paquets alternatifs
  3. Je ne connais pas Surveillance Station pour répondre. Tout ce que je peux affirmer est qu'effectivement faire une somme de contrôle (et les vérifs derrière) consomme évidemment un peu de ressources CPU. Ne connaissant pas la méthode utilisée par Synology je ne peux rien affirmer de plus.
  4. Cela prendra très longtemps mais tu auras une idée à la racine du système. A répéter dans les répertoires au fur et à mesure du tri... par exemple en alland dans /volume1 (cd /volume1). D'expérience, suivre le conseil de Zeus. C'est certainement le versioning de cloud station, drive... Cela n'est pas forcément un bug.
  5. Une sécurité haut de gamme? La qualité du pare feu sera surtout relative au temps passé à le configurer. Déjà se former sur la configuration avancée réseau de sa box ou de son routeur 😉 cela vous fera économiser 1000€
  6. Ha ben justement il est dit régulièrement que la veille des disques durs ce n'est pas bon. Du coup qui a raison? Cela se base sur quoi en fait ce conseil?
  7. Avec cette configuration vous n'avez pas de tolérance de panne. Mais puisque vous dites avoir une sauvegarde de vos fichiers (30To maximum quand même). Pour l'arrêt/démarrage effectivement cela entraîne des contraintes supplémentaires. Par conception, un NAS consomme moins qu'un ordinateur traditionnel et on considère que cela ne fait pas économiser grand chose.
  8. Il était écrit "cd /var" et pas "/var". En croisant vos 2 posts il semble que /volume1 dépende de /. Faites "df -h /volume1". Si le résultat ne renvoie pas qu'il est monté sur un FS propre à lui même (colonne Mounted on) c'est que c'est bien le cas. Faites alors "ls -al /volume1" pour voir ce qu'il y a dedans.
  9. Bonjour, la racine de votre système est plein. Généralement cela se passe dans /var le soucis: Cela listera par ordre de taille les dossiers du répertoire /var.
  10. Ou alors screen. Il n'empêche qu'il faudra lancer le script après chaque démarrage du NAS.
  11. Il me semblait qu'il y avait clamav pour Synology (enfin certains modèles). https://www.synology.com/fr-fr/dsm/packages/AntiVirus "Disque mirroir" si je comprends bien vous étes en RAID1. Donc l'encryption s'est répercutée normalement rapidement sur l'autre disque.
  12. Les permissions d'accès (lecture) sur les dossiers/fichiers de votre dossier partagé.
  13. Les permissions sur le dossier partagé, lorsqu'accédé via votre PC sous Windows, ne sont pas suffisantes pour voir l'intégralité des fichiers du dit dossier partagé. Sur vos captures d'écran: File Station : 35835 fichiers Windows : 20589 fichiers
  14. là de suite non sinon je n'aurais pas gardé l'information pour moi 😉
  15. Parce que vous n'avez pas fait la redirection dans le fichier. Parce que "192.168.1.100/home/root/.ssh/authorized_keys" ce n'est pas une commande. Sur le serveur B, le contenu du fichier de l'utilisateur root ~/.ssh/id_rsa.pub du serveur A doit être copié dans le fichier /home/root/.ssh/authorized_keys
  16. Redémarrer DSM 6.2 je ne sais pas ce que cela veut dire. Par contre redémarrer le NAS: shutdown -r now
  17. C'est le chemin complet de la home directory de l'utilisateur admin sur 192.168.XXX. En gros, copiez le contenu du fichier de la clé publique de l'utilisateur qui lance la commande rsync sur le serveur source dans le fichier /home/admin/.ssh/authorized_keys de l'utilisateur admin du serveur de destination
  18. Vous dites des bêtises par méconnaissance. Cela arrive. Ce n'est pas grave. Par contre, ici c'est un forum francophone d'utilisateurs de produits Synology. Ce n'est pas la société.
  19. lordtaki

    Bonjour et bonne année

    10Mb/s => grosso modo 1Mo/s Quel rapport avec le mode d'emploi?
  20. Bon apparemment le ssh ne gère pas la syntaxe user@ip... de toute manière c'est pas grave puisque vous n'avez pas fait d'échange de clés SSH. Un exemple parmi d'autres: http://wiki.pedrono.fr/index.php/SSH_-_Echange_de_clés_RSA Grosso modo sur votre NAS en tant que l'utilisateur qu iva lancer le rsync vous faites un keygen. Ensuite sur le serveur distant avec le compte utilisateur 'admin' (puisque c'est celui que vous utilisez dans vos commandes), ajouter la clé publique généré dans le fichier authorized_keys.
  21. Avez-vous vérifier l'échange de clé SSH? Au lieu de faire la commande rsync faites simplement: ssh admin@192.168.XXX
  22. Histoire d'être certain refaites une indexation. Si cela persiste c'est une limitation du lecteur multimédia de votre téléviseur. A essayer alors en utilisant Plex.
  23. lordtaki

    Docker et Transmission

    Ce dont vous avez besoin est un bind mount: https://docs.docker.com/storage/bind-mounts/ Si vous avez un docker compose: https://docs.docker.com/compose/compose-file/#volumes