CoolRaoul

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.

@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 ......

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.

Je te crois bien entendu sur parole, je tenais juste à souligner qu'il faut éviter de généraliser ("ipsec avec Android+syno ne fonctionne plus depuis quelques versions d'android"). La grande fragmentation d'Android, ajouté au différentes implémentations faites par les constructeurs fait qu'on se retrouve dans ce genre de situations floues ou ca marche pour certains et pas pour d'autres. D'ailleurs, tout ça m'a rapellé qu'avant d'avoir le Mororola j'avais également longtemps galéré avec mon Sony Xperia Z (CF ce fil: VPN L2TP/IPSec: histoire de fou)

J'ai remonté l'historique. Ca m'a permis de retrouver un de mes post dans un autre forum ou je témoigne de la dernière upgrade android reçue par mon smartphone. Ce dernier est daté du 20 Avril: http://forum.frandroid.com/topic/241978-help-cest-quoi-cette-mise-à-jour-régressive-en-60/?do=findComment&comment=3608637 Comme vu plus haut, le 22 avril (mon Moto X était donc déjà sous Android 6), la connexion VPN Android -> Syno marchait dans mon cas . Reste donc deux hypotheses: que la regression soit du aux patches de sécurité Android que j'ai reçu entre temps, courant Juin, ou que DSM (ou VPN server) soit en cause. Enfin, quoi qu'il en soit, faut bien que je me rende à l'évidence: que je peux sans doute tirer un trait sur l'utilisation du VPN Ipsec dans l'immédiat. Dommage.

Ca fonctionnait pourtant précédemment avec le même téléphone et la même version d'Android sous réserve d'avoir appliqué la bidouille expliquée ici (ajouter "sha2_truncbug=yes" dans /var/packages/VPNCenter/etc/l2tp/ipsec.conf). La seule chose qui à changé entre temps c'est DSM

Tiens puisqu'il est question de VPN server, la connexion vers le NAS en mode L2TP à partir de mon smartphone Android a cessé de fonctionner du jour au lendemain, probablement suite à une mise à jour DSM mais je ne saurais pas dire laquelle (je n'utilise pas le VPN si souvent que ça) Lors d'une tentative de connexion, la commande tcpdump ci dessous en ligne de commande sur le NAS me montre bien du trafic entrant et sortant, donc les redirections de ports n'ont pas sauté dans la box: tcpdump udp port 1701 or udp port 500 or udp port 4500 Hélas débugger tout ça est largement au delà de mes capacités. En attendant mieux, je dois me contenter de l'OpenVPN de ma Freebox (l'inconvénient est que je ne peux pas utiliser l'option "VPN permanent" sous Android dans ce cas.

Depuis DSM6, l'interface http d'admin DSM applique le titre "Authentification" à toutes ses fenêtres navigateur (du à la présence du tag "<title>Authentification</title>") dans le source de la page: C'est pas bien grave, mais je pense que quelque chose de plus spécifique ("DSM" par exemple et tout simplement) serait pas plus mal (le titre actuel est un peu trop générique pour faire matcher proprement mes entrées Keypass dans mon cas perso). Si quelqu'un peux faire remonter la suggestion.

Faut avouer... plus de deux mois après.. j'ai bien failli rater la réponse (d'autant plus que les notifications du forum marchent quand elles veulent ) Ben ... c'est "7z" et je l'ai écrit pourtant: "En ligne de commande il y a 7zip (commande: "7z", disponible sous DSM6) Je pensais que le lien vers la doc aurait été suffisant pour trouver (d'autant plus qu'elle contient des exemples). Bref, en résumé, la commande pour extraire tous les fichiers d'un iso en conservant la structure de dossiers/sous-dossiers est: 7z x <chemin>/<nom>.iso -o<répertoire_destination> remplacer "x" par "e" pour extraire les fichiers contenus dans l'iso "à plat" (sans recréer les sous dossiers) remplacer "x" par "l" (comme "lister") pour simplement lister le contenu du .iso <répertoire_destination> sera créé si necessaire

Mouais, en ce qui me concerne vu que mon port 443 est également ouvert à l'extérieur, avoir également le 80 ouvert ne change rien en terme de sécurité, suis ni plus ni moins vulnérable.