CoolRaoul

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.

C'est le cas, j'ai eu l'occasion de le constater tout récemment: https://forum.synology.com/enu/viewtopic.php?f=145&t=120588&p=445644#p445644

En complément à @Fenrir, le principe est que les règles du firewall s'appliquent de haut en bas. Des que la condition d'une règle est vérifiée, l'action correspondante (autoriser ou refuser) est sélectionnée et les règles suivantes sont par conséquent ignorées. Si aucune condition s'applique, c'est l'action par défaut ("si aucune règle n'est remplie") qui est sélectionnée. En général je préconise de commencer par une règle "open bar" qui autorise le réseau local (192.168.XX.YY en général) pour ne pas se retrouver bloqué. Et ensuite c'est selon son usage.

C'est sympa mais ça ne sera pas necessaire: j'étais à la recherche d'un serveur webdav un peu plus configurable que celui fournit par Synology et comme Owncloud en contient un j'envisageais de l'utiliser.Mais je me rend compte que ça risque d'être un peu trop surdimensionné pour mon besoin.

Ok mais j'imaginais également que le gestionnaire de paquet DSM6 (sous lequel tourne mon NAS) aurait été capable de ne m'afficher que les paquets compatibles (il est vrai qu'il n'est sans doute pas capable de le savoir)

Sur mon DSM213J, le Owncloud de Synocommunity est bien proposé que dans le gestionnaire de paquets Je croyais que seul les paquets compatibles étaient "visibles"

Je m'étais laissé dire que HSGT était vraiment un cran au dessus des autres niveau fiabilité (et prix aussi malheureusement). Quelqu'un saurait-il si c'est toujours le cas? Au passage même si je suis tout à fait d'accord pour dire que c'est la sauvegarde qui est essentielle pour la sécurité des données, des disques qui ont moins de risque de tomber en panne c'est toujours agréable, car une restauration est toujours un peu emm*** à se taper (d'autant plus que Syno ne dispose pas de methode bien documentée et universelle de sauvegarde "full" avec restauration from scratch de type "bare metal" que je sache). Je sais que le jour ou je renouvellerai mon NAS, en ce aui concerne le choix des disquesm le critère de fiabilité sera largement en tête (et loin devant les performances, d'autant plus qu'il s'agit d'un usage "familial" dans mon cas) et s'est pas toujours facile de s'y retrouver.

Il n'y a aucune différence avec ce que tu t'apprétais à faire avec Optware (AKA "ipkg"), juste qu'en utilisant ce script au lieu de celui que ty t'apprétais à utiliser (sous réserve que j'ai bien compris la question initiale), tu n'auras pas besoin de Optware, rien à ajouter à DSM. En résumé tu dépose le script ou tu veux, ensuite le rendre exécutable (commande "chmod +x <chemin du script>"), modifier les variables initialies et ensuite pour l'exécuter, soit dans une fenêtre terminal (mieux vaut commencer ainsi d'ailleurs pour la mise au point), soit via le planificateur de taces (dans le panneau de configuration DSM). Tu peux utiliser le compte "admin" pour l'exécuter, pas besoin de "root" Tu trouvera plein d'exemples dans le forum.

Autre méthode: j'utilise un script maison pour faire un miroir local via ftp d'un site web situé chez un hébergeur externe. Il utilise exclusivement des commandes disponibles sous DMS6 (pas besoin d'optware donc). Me semble même que "lftp" était *déja* disponible en DSM5 dans le package Download Station (désormais c'est de base dans DSM). En outre, comme il fonctionne en mode miroir (commande lftp "mirror") c'est très efficace quant il y a peu de modifications. Voici: #!/bin/ash PATH=/bin:/usr/bin # remplacer les variables ci dessous host=ftp.monfournisseur.net password=XXXXXXX user=UUUUUUUUUU dest=/volume2/backups/websitemirror # destination du répertoire miroir sur le NAS mkdir -p $dest chmod go= $dest lftp <<EOF set ssl:verify-certificate no open $host -u "$user,$password" mirror -v . $dest/. EOF

Je rencontre le même problème (depuis vendredi) quand je me connecte à partir du réseau de mon entreprise Par contre c'est Ok à partir de mon domicile ou de mon mobile J'ai demandé à un des responsables réseau de ma boite de diagnostiquer, d’après ce qu'il a constaté ça pourrait être des problèmes de peering entre le réseau utilisé par Syno et ceux de certains prestataires européens. Bon, après ça je n'en sais pas plus, ca dépasse mon périmètre de compétences.

Tu n'aurais pas imaginé si bien dire! l'expression exacte dans la réponse du support est: "il ne s'agit pas d'une anomalie mais du fonctionnement par "design" de l'application DS Video" "it’s not a bug, it’s a feature"

Reçu une réponse du support (j'avais ouvert un ticket). Il s'agirait du fonctionnement "normal: dès lors que MX Player est installé, DS Video ne permet plus à l'utilisateur d'utiliser le lecteur de son choix et impose ce dernier. Une proposition d'évolution va être proposée pour conserver le choix dans ce cas. J'avoue que ça me laisse perplexe, pourquoi ne pas avoir choisi de *toujours* laisser le choix? (à la limite via une préférence dans les options de DS Video "utiliser automatiquement MX Player si disponible", positionnée à "on" par défaut)

C'est fort probable: tu peux essayer d'ouvrir un fichier video de ton téléphone par l'intermédiaire d'un gestionnaire de fichier. Si tu constate la même anomalie (pas de "ouvrir avec") c'est qu'en effet il s'agit d'un autre problème. Notes aussi (mais j'imagine que tu dois le savoir) que, quand, dans le menu "ouvrir avec", on coche la case "toujours", c'est bien le comportement que tu décris qui va se manifester: plus de menu "ouvrir avec" pour les ouvertures suivantes du même type de fichier.

Il ne me semble pas que tu décrives le même phénomene que moi. Tout d'abord je n'observe ce comportement anormal *uniquement* dans le cas ou MX Player est installé. Dans cette configuration en effet, DS Video cours-circuite entièrement la méthode native Android de sélection du lecteur par défaut (et d'ailleurs la procédure de reinitialisation de valeur par défaut que tu mentionnes ne s'applique pas). Par contre, quand MX Player n'est *pas* installé, tout se passe normalement avec le respect du choix utilisateur quand on coché "toujours" ou avec le menu de selection du player sinon. Pas sur que ce soit corrigé rapidement, j'ai en effet entre temps retrouvé ce post sur le forum de support officiel ou un contributeur témoigne également de ce même défaut: "Surprisingly, after reinstalling MX Player, it became automatically the default player for DS Video, whereas before, it would prompt which player I wanted to use (and I would select VLC)." le message étant daté de septembre 2014 laisse deviner que le bug n'est pas nouveau. Bon, après c'est pas terrible non plus: je vais très certainement définitivement tirer un trait sur MX Player pour adopter VLC qui s'est énormément amélioré récemment. Ca masquera le problème.

J'avais lu lu ça mais je ne pense pas qu'on doive s'inquiéter (dans le cas de liens entre dossiers partagés en tout cas). Je viens à l'instant de faire un test avec un lien symbolique pointant vers un dossier situé dans un autre partage Dans ce dossier j'ai créé deux sous-dossiers, l'un avec des droits ACL "ouverts", et l'autre restreints. Un utilisateur non autorisé n'a non seulement pas acces au dossier restreint mais il ne le visualise même pas dans l'explorateur. Donc les droits affectés au dossier cible du lien sont bien pris en compte (et c'est heureux) **EDIT** Par contre il est important de garder à l'esprit que cette méthode utilisant les liens symboliques n'est apparement compatible uniquement avec les partages windows (CIFS), vu que ca se positionne dans les paramètres avancés de la section "partage de fiichiers Windows" de DSM. Ca reste invisible dans FileStation par exemple (faudrait éventuellement vérifier les autres modes d'acces).

Pour en revenir à la méthode s'appuyant sur des liens symboliques, je me demande si l'option ci-dessous (pas testée de mon coté) ne répondrait pas à la demande:

Je bute sur une anomalie étrange avec la version Android de DS Video (et c'est pas nouveau) Voici: Si MX Player est installé sur mon appareil, DS Video le choisit *systématiquement* pour jouer les video sans me donner la possibilité de spécifier une autre appli: Etat initial: MX Player désinstallé, VLC installé activation lecture de video dans DS Video: demande de choix du lecteur par défaut, je sélectionne VLC et coche "toujours" 2ème lecture de video: VLC est alors utilisé directement (ce qui est le comportement normal attendu) Installation MX Player nouvelle lecture video dans DS Video: cette fois pas de demande de choix ni d'utilisation de VLC: MX Player est automatiquement utilisé sans me demander mon avis! désinstallaton MX Player: le choix par défaut (VLC) est de nouveau pris en compte. Note: j'avais pu constater le même comportement avec le lecteur vidéo intégré à ES Explorer (que je n'utilises plus). Si ce dernier est installé et pas MX Player, DS Video choisit alors celui-ci sans aucune possibilité de du choix utilisateur. Ce qui laisse à penser que le problème est bien du coté de DS Video. J'ai testé également sur ma tablette et j'ai le même comportement.