CoolRaoul

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.

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.

Bug du planificateur de taches que j'ai déjà rencontré dans le cas des taches exécutés sous un compte non root Suffit d'ajouter "cd /tmp" en début (me semble que "cd" tout court plante aussi car $HOME n'est pas défini cans certains cas, à vérifier) Tant qu'a faire, plutôt utiliser: find /volume1/ -type f -name *.mkv -mtime +4 -delete plus efficace (pas de fork de process)

Le mien tourne comme une horloge sous DSM6, et je serais vraiment frustré de devoir me limiter aux fonctions disponibles en 4.3, il y a eu bien des nouveautés et améliorations depuis. Sachant que le 213j dispose de 512Mo de RAM (ça a été le premier modèle Synology d'entrée de gamme à être aussi généreusement fourni) il n'a aucun problème de capacité à faire tourner DSM6 (d'autant que CPU est largement suffisant, je ne suis même pas certain que DSM6 soit plus exigeant que DSM4 sur cet aspect)

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.