TheShurikn

Hello, C'est top comme astuce, un grand merci à toi!!! En revanche, pourquoi tu déconseilles voir proscrit le montage automatique constant? Si je branche les DD sur un autre Syno et que je reboot le Syno, les dossiers vont se remonter automatiquement? Si c'est le cas, je ne vois pas trop l'intérêt de chiffrer avec un montage automatique... car avec n'importe quel NAS je peux accéder aux fichiers... ++ §hu

Vous ne voyez pas de problème? Ce répertoire "home" ou CloudStation se synchronise ne vous semble pas le plus critique? C'est la ou tous les users vont mettre leur données perso/professionnelles, c'est le dossier le plus critique si l'on utilise CloudStation. C'est d'ailleurs une des grandes avancées du DSM 5! Il est plus qu'évident que si l'on souhaite faire un backup de son syno, c'est un des 1er répertoire que l'on va backuper... et sans cryptage et ben c'est juste pas pensable! Pas de backup sur un autre cloud ou sur un autre Syno (d'un ami ou autre), car l'accès aux fichiers de tous les users sera disponible en clair!!! J'espère que vous voyez un peu plus l'importance à présent! Pour moi c'est LE dossier critique ce HOMES ! ++ §hu Tu m'expliques comment tu fais avec CloudStation?

Voici la réponse pathétique du support français: Non mais allo quoi!!!! J'attends une réponse plus sérieuse... ++ §hu

Ouais bah ils font bien ch.... car c'était possible en DSM 4, ça j'en suis certain. Lancer le chiffrage d'un dossier via ssh peut-être? Le dossier que je souhaite crpyter est le "homes" pour cloudstation, cela semble tellement évident... mais ce dossier est créé à l'activation du service. Bref pas top sur ce coup synology! ++ §hu

Hello, Je souhaite crypter/chiffrer un dossier racine qui est déjà existant mais je ne trouve pas l'option. L'option est disponible lors de la création du répertoire mais une fois créé l'option n'est plus présente Je suis persuadé à 99% que sur une ancienne version de DSM (la 4 peut-être), j'avais pu chiffrer un dossier partagé après sa création... Je précise que je suis bien logué avec un compte admin et version de DSM: 5.0-4493 update 4 Merci par avance ++ §hu

Réponse constructive au moins... ++ §hu

Bonne nouvelle, il a effectué le scan en 1min30 C'est déjà ça! ++ §hu

C'est sympa (pour le script), merci mais j'ai fait l'inverse, toutes mes vidéos sont renommées selon IMDB (à la lettre prête ), du coup tout est quasiment scrapé sans erreur. Bon bah je vais relancer un scan en espérant que cela ne se reprosuise pas. ++ §hu

Hello, Voici ma config: - Webdav activé en https uniquement en laissant le port par défaut (5006). - Activé l'option DS File dans QuickConnect - Port et 443 ouvert sur mon routeur - Port et 443 autorisés sur le firewall depuis n'importe quelle connexion - Tous les ports autorisés sur le firewall pour toutes les connexions LAN J'utilise l'identifiants sous forme de chiffre donné par QuickConnect et l'accès fonctionne de manière aléatoire. Sans changer de réseau, cela me refuse parfois la connexion, je réessaie une, deux ou trois fois puis tout d'un coup sans n'avoir rien changé, j'arrive à me connecter. Donc ça fonctionne parfois du premier coup mais pas toujours et indépendament du réseau sur lequel je suis connecté (que ce soit en Wi-Fi LAN, en Wi-Fi Wan depuis mon job, en réseau GPRS...). Lorsque la connexion est refusée, je peux avoir divers messages d'erreurs, du style (je ferai des printscreen lorsque cela se produit pour être plus précis): - Assurez-vous que le serveur WebDav est bien activé sur ce serveur distant - Aucun fichier/dossier n'est présent dans ce répertoire Un reboot du Syno ne change rien. Qqu'un rencontre-t-il les mêmes problèmes? ++ §hu

Reboot du Syno = idem mais pas encore testé le stop/start de video station... je ferai un édith de ce poste une fois tenté. ++ §hu

Depuis DSM 4.3 tu peux paramétrer les droits d'accès par user dans Video Station. ++ §hu

Hello, Soudainement, sans avoir changé aucun paramétrage dans Video Station, plus aucun dossiers vidéos/series ne sont présent. Les films scrapé sont toujours bien la mais plus aucun dossier n'est présent dans le paramétrage. Le seul changement système que j'ai effectué c'est l'activation de l'authentification en 2 étapes (google authenticator) pour le compte admin. Peu importe le login utilisé j'ai les même erreurs: Qqu'un d'autre à les mêmes prob? Vous me direz que c'est pas bien grave, je peux les rajouter mais c'est étrange et j'imagine qu'il va me refaire l'entier du scan... ++ §hu

SEND en les traitant d'apple developper marketing man ++ §hu

Demandeur leur juste le pourquoi (Why?) de cette sélection? Ressources systèmes importantes pour lire du HFS+? J'ai qqu doutes quand-même... on dirait du Apple sur ce coup... ++ §hu

En effet, lors des tests j'avais un DS713+ et à présent un 412+... navré pour la fausse joie ++ §hu

Ok, merci Piwi pour ces précisions, je comprends mieux à présent. Mais je ne comprends pas bien pourquoi je ne vois pas les identifiants lorsque je me log sur DSM. J'ai voulu checker avec Wireshark mais le filtre que j'avais en mémoire ne fonctionne pas avec le https, je n'ai donc pas pu tester mais je vais approfondire dès que j'ai un moment. Pour répondre à pluton: ce que j'ai pu constater c'est que tous les éléments ne sont pas en https dans la page. Au vu du code il y a des iframe et je pense que le hic vient de la et certain navigateur le signal, d'autre pas. ++ §hu

Comment tu expliques que via l'interface DSM la commande POST n'envoie aucune information en clair avec cet outil? Dès que j'ai le temps, je fais un check avec Wireshark. ++ §hu

Voici quelques tests effectués mais avant j'oubliais de préciser que je suis sous PhotoStation 6 (et donc en version Beta). Finalement les commandes envoyées sont bien en POST (et non en GET comme annoncé précédemment). Le passage DSM à PhotoStation ne transmet pas les identifiants, il effectue un check au moyen d'une api (vérifie si le user est déjà logué via un cookie). Ce point est donc résolu. En revanche si on se log depuis la page de PhotoStation en https, les identifiants sont envoyés en clair sur le réseau. En image: Et comme différence, voici ce que j'obtiens lorsque je me log via l'interface DSM (tout est OK grâce au script encryption.cgi) ++ §hu

Je viens de refaire le test avec Wireshark et HttpWatch, dans les deux cas le login+mdp est envoyé en clair lors de la connexion. En revanche je n'ai pas testé le basculement de DSM à PhotoStation... ++ §hu

Hello, En saisissant l'url à la main (car pas de redirection auto possible): https://mondomaine.com/photo les commandes de login sont envoyées en GET sans script CGI. Ce qui a pour effet d'être envoyée en clair sur le réseau. Autrement dit, l'activation du HTTPS pour PhotoStation est complètement inutile au niveau cryptage des données! Il suffit de sniffer le réseau pour s'en aperçevoir! C'est quand-même fou à l'heure actuelle! Surtout qu'ils viennent d'effectuer une refonte majeur avec la V6 en beta! Et c'est même traitre comme comportement car on se log en https sur DSM puis en cliquant sur un bouton (PhotoStation), hop les identifiants sont balancés en clair! Faites-vous le même constat et ne trouvez-vous pas ceci limite!? ++ §hu

Super, merci pour ta réponse! Je vais conserver cette otpion en dernier. Je vais wiresharker lol, j'arriverai peut-être à qqu chose... les .css ne me donnent rien... ++ §hu

Hello, Je souhaiterai via un lien html rediriger directement sur la mir de login de photostation. En effet je n'ai aucun album public et le bouton connexion n'est pas des plus évidents lors de la 1ère visite. Qqu'un aurait un tips? ++ §hu

Le seul moyen de définir une photo de couverture c'est d'avoir une image à la racine de ce dossier. Point remonté à Synology, ils en sont conscient, j'ai reçu leur réponse dans ce sesns. ++ §hu

Merci pour la réponse.... du coup je vais chercher ailleurs mon problème ne vient pas de la. ++ §hu