CoolRaoul

Je me demande de quel chapeau sort ce "fullfilename" De plus le formalisme ${nom%.*} est typiquement (et peut être exclusivement) Korn shell **edit** Au temps pour moi, je constate sur sa man page que ash (qui est le shell de DSM) connait ce formalisme. Mais reste ma question sur la variable "fullfilename"

A moins qu'il s'agisse d'un service gratuit, faudrait nous donner le nom de ton fournisseur. Un service de ce genre qui ne permet même pas de gérer librement ses sous domaines en leur affectant des IPs différentes est a fuir d'urgence.

Dans l'éditeur, pour coller, le faire via un simple Control-V ou shift+insert ne devrait pas poser de problème. Sinon, reste a envisager hypothèse de l'incompatibilité d'une extension du navigateur (type adblock) avec le code javascript de l'éditeur. Faudrait tester avec les extensions désactivées, et/ou un autre navigateur pour en avoir le cœur net

En plus de sauver les données, simultanément à de chaque job de sauvegarde est effectuée une sauvegarde des settings DSM (compte utilisateurs, partages, etc...). C'est la même chose que l'on trouve dans le panneau de configuration -> Mise à jour et restauration -> Sauvegarde de configuration. Ce de ça qu'il est question ici.

Dans la sauvegarde, "incrémentale" signifie simplement que chaque sauvegarde successive n'envoie vers la cible que les fichiers modifiés depuis la sauvegarde précédente, mais pas que ça gère les "versions de fichiers" Sous DSM, je ne connais pas de méthode native pour faire ce que tu veux (multiples versions) avec pour destination un serveur rsync. Il y a bien le backup "multi version" mais ça ne fonctionne que si la cible est un volume dédié sur le même NAS. TimeBackup () se rapproche un peu plus de ton besoin, mais je ne sais pas si il fonctionne à travers le réseau mais en tout cas pas avec un serveur autre que Synology comme cible.

Et bien, je ne comprend toujours pas le probleme! Les liens créés par DSM, meme si ça affiche "http", sont utilisables en http et https, et de toutes facon faut bien les copier/coller à la main pour les communiquer par mail ou autre, je me trompe? Suffit d'ajouter le "s" a ce moment la, c'est pas compliqué.

Décidément, j'ai du mal a capter aujourd'hui: je ne comprend pas non plus le sens de cette phrase (souligné) Pour résumer, lors de la création d'un lien de partage, DSM génère la partie *chemin* de l'url (ce qui suit le premier "/" simple dans l'url), et c'est celle-la qui fait foi pour accéder au fichier. Pour le host c'est celui configuré dans le panneau de configuration. Que s'affiche dans la fenêtre de dialogue et dans le gestionnaire de liens partagés "http" ou "https" ne change rien au fait que https *et* http fonctionnent tous deux. Je ne vois pas ou est le problème.

Je ne suis pas sur de comprendre ce que tu veux dire par "l'addresse n'est pas éditable". Puisque il s'agit de faire un copier/colller dans un mail Tu remplace "http" par "https" dans la version copiée et c'est bon! Ca reste affichée en "http" dans le gestionnaire de lien partagés mais bien évidemment les deux protocoles peuvent indistinctement être utilisés.

Pour ça, il suffit de mettre l'adresse externe dans le panneau de configuration DSM, accès externe, avancé, "nom d'hôte ou ip statique"

Pour l'acces fichier ("systeme de fichier" désignant plutot la *structure* sur disque, comme ext4fs dans le cas du Syno ou NTFS sur PC Windows) le choix est assez simple: quasiment personne n'utilise SMB a travers internet (sauf via un VPN). Par contre, c'est le protocole de prédilection sur le LAN (en compétition avec NFS dans le cas de clients Linux/Unix). Apparemment, même Apple a choisi de privilégier SMB par défaut. Webdav est un protocole encapsulé dans de l'http, et donc sa sécurité est du même niveau que HTTP lui même. Niveau authentification, c'est inévitablement compte/mot de passe. Niveau confidentialité ça sera crypté si ça passe à travers SSL. Mais attends d'être certain d'en avoir besoin avant de l'activer et ouvrir ses ports pour acces distant. Avec un smartphone, DSFile peut être suffisant et s'appuie sur les ports "standards" DSM (5000/5001).

Je suis pas entièrement catégorique sur la désactivation du compte admin: mettre un mot de passe bien fort à ce dernier le rend aussi difficile à craquer qu'un compte admin annexe (sur lequel bien entendu il faut quand même mettre un mot de passe sérieux), il y a juste le fait que le nom "admin" est déjà connu. Mais faut pas oublier que c'est le couple [compte X mot de passe] qu'il s'agit de découvrir pour entrer. Par contre des que le NAS est accessible de l'extérieur, je considère *impératif* de s'assurer que le blocage auto est activé, c'est à mon avis la première et la plus importante des mesures de sécurité à prendre. Sachant qu'un potentiel attaquant n'aura (avec la config par défaut) que 3 essais avant de voir son IP bloquée pour 24 heures, toute attaque de type "brute force" est complètement inhibée par ce mécanisme. Autre conseil: dans la mesures on on décide d'ouvrir en externe l'acces SSH, pour éviter de se retrouver sous un déluge d'alertes de tentatives de connexions, lui affecter un autre port que le traditionnel 22 peut être une bonne idée (ça ne change pas fondamentalement le *niveau* de sécurité, c'est juste pour moins stresser). Le plus simple et efficace est de le faire via la règle de redirection de port de la BOX si elle le supporte.

Commencer par copier l'un des fichiers directement sur l'appareil de lecture (PC ou Smartphone) et tenter de le lire ainsi, avec la même application mais en acces direct Essayer aussi de vérifier le fichier auinsi copié, avec Mediainfo, quelles sont les pistes de sous-titres effectivement embarquées dans le container

Ca n'a rien a voir: la mise en veille des disques (ce qui est déconseillé par ailleurs mais c'est un autre débat) n’empêche pas le NAS d'être accessible normalement par le réseau (quel que soit le protocole). Les disques vont arrêter d'être alimentés et le seront de nouveau des qu'un accès fichier sera nécessaire. A l'inverse, le WOL permet de réveiller un NAS *complètement éteint* (power off) à partir du moment ou il est toujours connecté au secteur: dans ce mode seule la carte réseau est alimentée, suffisamment pour intercepter les "paquets magiques"

Je pense qu'il serait utile d'avoir des retours individuels sur la qualité/sérieux/fiabilité de ces repositories. Je conçoit que ça peut être un boulot fastidieux, mais une liste d'URL sans commentaires ne me semble pas suffisante. Pour ma part, j'ai des réticences à connecter le gestionnaire de paquet de mon NAS à des sources de packages dont je ne connais rien d'autre que l'URL: y a pas mieux pour diffuser des malwares et autre trojans à (relativement) grande échelle De plus j'imagine que la plupart ne permettent pas une connexion SSL via un certificat correctement signé (ce qui est le cas de synocommunity qui accepte l'url https://packages.synocommunity.com/ par contre), nous assurant qu'il n'y a pas d'usurpation d'identité de site à l'autre bout.

Non, tu as raison. Contrairement à ce que je pensais, tous les modèles au catalogue ne supportent pas encore le wake on lan C'est traduit en français pas "Sortie de veille LAN/WAN" dans les fiches produits Syno, comme ici: https://www.synology.com/fr-fr/products/compare/DS214se/DS213j

Ca dépend du modèle du NAS: toute la gamme Synology ne supporte pas le Wake On Lan. Faut vérifier les specs (mais généralement il me semble que tout les modèles pas trop anciens le supportent) Et alors, si le NAS est compatible, pas de problème, il existe des tas d'applis pour ça, même pour smartphone.

Il suffit que les droits du dossier photo, vus que ce soit via filestation ou SMB, soient tels que le serveur web Apache ait accès en lecture/écriture à l'intégralité des dossiers et fichiers qu'il contient. Idéalement seul les comptes administrateurs DSM devraient avoir un autre accès. Chez moi par exemple, au niveau des droits unix, c'est user=http et groupe=http, mode="rw(x)rw(x)---" Quand on accède aux photos comme il se doit exclusivement via PhotoStation et DSPhoto (aussi bien en consultation qu'en upload), ce sont d'autres droits qui sont effectivement pris en compte, ceux gérés de façon interne à PhotoStation. En gros on peut considérer l'intégralité du partage "Photo" comme la propriété exclusive de Photostation. Ce n'est que par son intermédiaire (sachant DSphoto n'est qu'un client de PhotoStation) que les droits doivent être contrôlés.. **EDIT** je reconnais que cela peut être contraignant vu que ça interdit de fait à un utilisateur non admin d'utiliser une application tierce pour manipuler les photos, mais si on analyse comment fonctionne photostation c'est le mode de fonctionnement qui semble être prévu par Synology.

Fonctionnellement parlant, tous les modèles de la gamme Synology disposant d'au moins deux baies répondent à ta spec (donc les références "DSNXXX" avec N >= 2). D'autant plus, qu'a quelques fonctions "pro" prés, l'ensemble de la gamme dispose des mêmes outils et du même operating system. Par contre (et comme on n’arrête pas de le répéter sur ce forum), un raid n'est *pas* une sauvegarde: on n'est jamais à l'abri d'une corruption du système de fichier, ou d'une suppression malencontreuse (appli défaillante, ou mauvaise manip utilisateur). En fait le RAID a deux objectifs: assurer une haute disponibilité en cas de panne matérielle d'un disque (délai de remise en service minimisé), et/ou améliorer les performances (suivant le type de RAID). Mais considérer que ça permet de s'abstenir des sauvegardes n'est pas une bonne idée.

Je me demande si tu utilises le dossier "photo" de manière optimale. Regarde ce que j'ai déja écris sur le sujet:

Ca, faut avouer... à se demander si tu ne t'es pas carrément trompé de forum: quel rapport avec les NAS? (Synology ou autres d'ailleurs)

Pas obligatoire d'installer DSM 5.1 beta pour tester notestation, cf mon message ici:

Ne pas négliger l'option d'utiliser un smartphone avec 3G activée et wifi désactivé, ça peut dépanner aussi (et éviter de "faire appel à un ami")

Faut éviter de toucher directement aux fichiers "/usr/syno/etc/httpd-ssl-vhost.conf-user" et "/usr/syno/etc/httpd-vhost.conf-user" Leur contenu est géré par DSM et est "parsé" lors de la sauvegarde de la configuration (qui est systématiquement faite lors de chaque job de sauvegarde). Si l'outil de sauvegarde ne comprend pas son contenu il peut planter. J'avais mis le doigt sur ce point il y a un bout de temps déjà (on était encore en DSM 4 alors): D'ailleurs, c'est en partie pour éviter cette obligation d'avoir à éditer des fichiers systèmes, avec les effets de bords indésirables qui peuvent survenir sans prévenir à chaque update de DSM, que j'ai choisi de définitivement abandonner la méthode apache pour passer à nginx pour implémenter le reverse proxy

Pour que les vidéos soient également prises en compte, "photos uniquement" ne doit pas être coché:

Ben voila, c'est arrivé (DSM 5.1 Beta)