CoolRaoul

Bon j'y vois plus clair Resterait plus qu'à choisir les modèles de HDD adaptés: si je me lance dans l'opération d'upgrade (je répète que rien n'est décidé pour le moment) ça serait un RAID5 (ou SHR) sur 3 disques (j'estime que 3X2TO me suffiraient même si c'est plus trop au gout du jour) + un volume simple (3 ou 4TO ce dernier). (désolé de faire dériver le fil en HS)

Tout à fait, et c'est aussi attisé par le fait que je me dis que quand les modèles 2017 seront annoncés, pourrait bien y avoir des affaires à saisir sur la gamme 2016. Mes besoins en puissante brute restant très raisonnables, je privilégie d'autres critères, et les économies d'énergie en font partie. Mais là je suis en peu dans le brouillard. (Pour l'aspect budget je sais bien que sont les disques qui de toutes façon vont absorber l'essentiel de la facture si je vais jusqu'au bout de la démarche)

Pas facile de faire une mesure avec un wattmètre sur un appareil qu'on n'a pas encore acheté et c'est quelque part la raison de ma question initiale. Plus exactement mon objectif est d'avoir une idée à peu pres réaliste de la consommation effective de chacun de ses modèles dans le contexte de mon profil d'utilisation.

Mais comment expliquer que différence entre les mode acces et hibernate varie de 22 à 9 Watts sur ces deux modèles 4baies si on prend en compte uniquement la consommation intrinsèque des disques? Mode DS416 DS416J Acces 31,96 W 21,60 W Hibernate 10,14 W 12,75 W diff 21,82 W 8,85 W Ca dépend: dans mon cas, s'agissant d'un équipement qui se trouve 99% du temps dans ce mode, c'est justement ce chiffre qui est le plus significatif (je n'active pas l'hibernation). **EDIT** Au passage je suis surpris que le modèle "j" ait une consommation supérieure au modele non "j" en mode hibernation.

Bonjour, Dans les fiche techniques disponibles en ligne (exemple), sont fournies la consommation électrique, respectivement en "accès" et en "hibernation disque dur": Consommation électrique* 31.96 W (Accès) 10.14 W (Hibernation disque dur) 21.6 W (Accès) 12.75 W (Hibernation disque dur) Qui saurait m'aider à extrapoler la consommation en mode "idle" (autrement dit pas d'hibernation disque mais pas d'accès non plus)

Tu as du oublier ou pas faire gaffe. Enfin, bref, c'est anecdotique Le principal est maintenant que tu appliques la modif de conf syslog qui t'a été suggérée pour avancer dans le diagnostic.

C'est vrai que j'oublie parfois que si j'ai les logs ssh dans syslog c'est grâce à cette astuce que j'ai appliquée depuis 2013 (ref) et je conclue un peu rapidement que tout le monde les a aussi. Avec ces modifs on devrait trouver l'explication je pense ce message indique juste que c'est la première fois que le compte root de spectr59 se connecte au NAS,

Non: les deux lignes suivantes du log client : debug1: identity file /home/spectre59/.ssh/id_rsa type 1 /../ debug1: Offering RSA public key: /home/spectre59/.ssh/id_rsa montrent bien au contraire que la clé id_rsa ("/home/spectre59/.ssh/id_rsa") est effectivement lue par le client ssh

Les logs coté client n'aideront pas des masses. Rien d'intéressant trouvé dans /var/log/messages sinon ?

C'est malheureusement insuffisant comme information. Ca indique souvent une erreur de syntaxe dans sshd_config, mais vu que la connection par mot de passe fonctionne, l'explication doit être ailleurs. C'est bien ce que j'imaginais et je confirme que c'est inutile: traditionnellement les paramétes en commentaires dans sshd_config sont précisément là pour illustrer les valeurs par défaut.

Bien sur que non, pas de lezard. Je suis parfois un peu trop intégriste de la précision sémantique

L'étape 3 est inutile déjà (ce sont les valeurs par défaut que tu as ajouté) Sinon jette un oeil dans /var/log/messages (grep sshd /var/log/messages | tail ) tu pourrais y trouver des pistes

La réponse à ma question ( "PC et NAS ne sont pas sur le même réseau") est donc "oui" . Pour l'accès webdav, normalement c'est possible directement via l'explorateur Windows, pas besoin de net drive ou autre logiciel similaire. Par contre c'est pas forcément trivial, il peut y avoir des réglages à faire dans la base de registre pour que ça passe. Je me souviens avoir pas mal galéré (sous Windows 7) avec ça il y a un bout de temps et j'avoue ne pas être sur de retrouver toutes les infos sur les manips requises.

Je suppose que PC et NAS ne sont pas sur le même réseau ? Car sinon je ne comprend pas la raison de toutes ces complications

La commande "mirror" (dont il était question quand j'ai répondu il y a deux ans de ça) n'a pas d'option pour ça (sinon ça ne serait plus un miroir). D’après la doc lftp ca peut se faire avec "mget -d" (pas eu l'occasion d'utiliser), attention toutefois aux risques de supprimer un fichier en cours de transfert.

Une solution peut-être plus simple (mais par contre dont les détails de mise en oeuvre sortent du cadre ce ce forum) serait d'installer sur le PC domicile un outil de prise de contrôle à distance (type TeamViewer), s'assurer de pouvoir démarrer le PC à distance (WakeOnLan, différentes solutions sont mentionnées par ailleurs dans d'autres sections du forum) pour ne pas à avoir à le laisser sous tension en permanence. Ensuite suffit d'utiliser le client TeamViewer sur le PC pro (pas besoin d'installation, un simple .exe à lancer) et voila, connecté au PC perso de l'extérieur pour y lancer l'application Grisbi pou Windows

Un rapide parcours des sources montrent qu'il s'agit d'un logiciel à interface graphique (s'appuie sur GTK). Même si compilation et installation à l'intérieur du Debian "embedded" dans DSM aboutissent, pour l’utiliser *à distance* va falloir mettre un place un tunnel ssh pour laisser passer les flux X11 et disposer d'un serveur X sur le PC de bureau (par exemple celui de Cygwin/X si il est sous Windows ), à installer si non déjà fait, ce qui contredit votre exigence ("éviter d'installer le logiciel sur mon micro professionnel") Note: si vous ne comprenez pas mon charabia c'est le signe que ce n'est pas la peine de perdre du temps la dessus En résumé c'est franchement pas gagné.

Pour ceux que ça intéresse, la liste des autres modèles dans ce cas est ici: https://www.synology.com/fr-fr/knowledgebase/DSM/tutorial/General/Which_Synology_DiskStation_supports_WOL_Wake_on_LAN

@tchampe au vu de se qu'on parvient à imaginer de votre infrastructure, il s'agit d'un NAS installé sur un réseau local d'entreprise avec les postes clients connectés au même réseau Si c'est bien le cas l'utilisation de Cloud Station drive n'est pas adaptée ici. Avec ce type d'architecture, les postes clients doivent pouvoir ouvrir les fichiers directement sur le NAS en accédant aux dossiers partagés déclarés sur ce dernier. Dans le cas d'un environnement Windows, vos utilisateurs devront accéder au NAS à partir du "voisinage réseau" dans l'explorateur, ou mieux, directement en utilisant les chemins explicites (de la forme \\nom_du_nas\dossier_partage\...\fichier). Ces méthodes étant également utilisables dans les boites de dialogue "fichier" -> "ouvrir" et "fichier" -> "enregistrer sous". Existe aussi l'approche de mapper des lettres de lecteurs mais j'ai tendance à déconseiller, un peu "old school" à mon goût. Dans le cas d'un environnement Apple, faudra compter sur d'autres utilisateurs pour vous aider, ça n'est pas dans mes compétences.

Vraiment bizarre ton problème Avec Excel en particulier, normalement le deuxième utilisateur qui ouvre le fichier devrait recevoir ce warning: Et ce n'est que si cet utilisateur sélectionne *explicitement* "lecture seule" qu'on constate le comportement décrit . On est bien d'accord que les deux utilisateurs accèdent au fichier via l'explorateur windows ou "fichier->ouvrir" dans Excel?

C'est tout à fait possible (et ne contredit pas ma remarque): comme j'ai indiqué, tout dépend de l'appli. Windows fournit des primitives de lock de fichier, si l'appli ne les utilise pas c'est son problème, mais Windows pas plus que le NAS n'est pas en cause.

Pas forcément: Windows dispose des APIs nécessaires pour gérer correctement le verrouillage de fichier, et ca s'applique autant au fichiers locaux qu'aux fichiers situés sur un partage distant sur un NAS ou autre serveur. C'est aux applications d'invoquer ces APIs. (Les applis Office le font correctement en général par exemple)

Un "déterreur" qui n'attend pas de réponse: http://www.nas-forum.com/forum/topic/25610-la-limite-dupload-dans-download-station-ne-sert/?do=findComment&comment=1319302861 Cohérent quelque part. Au passage sa réponse à ma remarque datée du 05 Juillet ne vient qu'aujourd'hui, plus de 2 mois après. Tout vient à point etc ......

Moins complexe? Avec l'utilisation d'un canal "data" et d'un canal "commande", l'ouverture de session TCP dans le sens *sortant* (dans le cas ou on n'utilise pas le mode passif) sur des ports alloués dynamiquement par le client et communiqués au serveur. (ref) Et en mode passif (à utiliser de préférence) il faut non seulement toujours ouvrir le port commande (TCP/22) dans le serveur mais également un intervalle de ports pour les flux "data": Note: les ports définis ci dessus doivent également être ouvert dans le firewall et redirigés dans le routeur Alors qu'en SFTP, suffit d'ouvrir le port TCP/22 (ou un autre si on a choisi une configuration personnalisée) et basta, tout le traffic passe dans un unique flux TCP entre client et serveur.

En donnant un exemple de cas d'usage je me doutais bien que ça ne s'applique pas à *tous* les utilisateurs. Dans ce cas, évidemment, la question ne se pose même pas vu qu'il est impossible sous Android d'empiler les VPN.