CoolRaoul

Il serait utile de vérifier si il est accessible dans le navigateur Internet aussi http://ip.du.nas:5000 Diskstation manager n'est pas indispensable

Et ma suggestion précédente ?

Essaie dans la barre d'adresse de l'explorateur de fichiers en y saisissant : \\ip.du.nas\ pour voir Exemple : \\192.168.0.20\

Ca manque de détails pour trouver une piste. Pour commencer, à partir de quelle machine "il n'apparait pas" ? Un PC Windows, un Mac, autre ?

Voir ici pour les détails de la configuration à utiliser : https://assistance.free.fr/articles/609

Pas l'intégralité non, uniquement les répertoires contenant des medias et déclarés dans les paramètres du service d'indexation (se configure dans le panneau de configuration). CI dessous la conf par défaut : Il s'agit du protocole de diffusion normalisé (DLNA) audio et video reconnu par la plupart des équipements de type téléviseur, ou applications de visionnage/écoute par exemple Et même pour ceux-ci, il est possible de restreindre accès par défaut dans les paramètres du media server. Autant à priori ("Restrict access to Media Server for newly detected UPnP/DLNA devices") pour les équipements nouvellement détectés qu'a postériori ("devices list") (Désolé pour l'affichage en anglais mais je configure ainsi pour convenance personnelle)

et pour la sauvegarde de la config j'ai trouvé ça : synowebapi --exec api=SYNO.Docker.Container.Profile method=export version=1 outfile="<fichier>" name="<container>" Quant au file system du container, "docker export" fait le job. Je pense que j'ai tout ce qu'il me faut

Je viens de voir qu'uil existe une API Rest "SYNO.Docker.Container" J'ai pu l'utiliser pour arrêter et démarrer un container. Il est possible que la sauvegarde soit disponible via cette dernière. Reste plus qu'à mettre la main sur la doc de l'API

Bonjour note : Je ne suis pas un grand spécialiste de docker, je m'aide des tutos glanés ici ou là. Je réfléchis à une stratégie de sauvegarde automatique de mes containers. Idéalement j'aurais souhaité pouvoir reproduire ce que fait la commande "export" en mode "contents and settings" de container manager mais je ne sais pas si une interface CLI existe En attendant j'ai un script qui effectue à peu près la même chose (que Claude AI m'a aidé à pondre) et que je pourrais automatiser par le task manager Il effectue les actions suivantes : Arret du container si pas arrêté Création d'une archive du contenu par "docker export" Création d'une archive compressée avec ces fichiers (issus de "docker inspect") container_config.json environment_variables.txt labels.txt networks.txt restart_policy.txt volume_mappings.txt plus l'archive issue du "docker export" de l'étape précédente Redémarrage du container (si il était "running" au départ) Est-ce que cette approche vous semble tenir la route? Question subsidiaire : Quelqu'un connaitrait-il une méthode pour produire un résultat identique à celui produit par le "export" de container manager ? (ça serait top)

A mon avis tout semble indiquer que le problème est côté télé plutôt que côté NAS. As tu essayé de poser la question sur un forum dédié Samsung ? Il existe une communauté officielle : https://eu.community.samsung.com/t5/français/ct-p/fr

Ça vaut ce que ça vaut mais j'ai un tout petit site chez Online/Scaleway. C'est une vieille formule hébergement+nom de domaine, plus disponible au catalogue actuel, mais dont ils maintiennent le support pour les abonnés existants (ce qui est tout à leur honneur). Je me permets de témoigner pour signaler la réactivité impressionnante de leur support client (y compris le week-end et en dehors des horaires standard). J'ai eu à ouvrir quelques tickets, ces derniers mois notamment, et ai toujours été extrêmement satisfait, autant de la rapidité de prise en compte que de la qualité des échanges avec les intervenants. Et tout ça malgré la minuscule contribution annuelle que j'apporte à leur CA. Je ne connais pas le reste de leur offre mais j'imagine que la qualité du support ne peut qu'être au moins de même niveau. Je n'ai bien entendu aucune action chez eux.

@Flamby55 par curiosité j'ai essayé de configurer la synchro de l'agenda Synology avec mon smartphone (c'est un Android) De mon côté je suis parvenu à le faire fonctionner (via l'application "DavX5" qui est necessaire sur Android) Juste une différence avec toi sur l'url : de mon côté j'ai utilisé l'URL https://MONNDD.myds.me:5001/caldav.php et renseigné les champs user et password dans le formulaire de l'application ( à ce propos j'ai été surpris de ne pas me trouver bloqué sur le MFA qui est activé pourtant sur mon compte Et ça se synchronise bien et dans les deux sens **edit** Ah j'ai compris, l'URL est différente si on configure accès par alias dans le portail de connection. Avec le nom que j'ai choisi, "caldav", alors https://NDD.myds.me/caldav/ fonctionne pour moi (mais je n'ai pas le "/User" toutefois ni le port DSM 5001, ça passe par le port 443 SSL standard) Comme je suis sous Android et toi sur IOS je ne pourrais hélas sans doute pas t'aider plus avant

Il est important de comprendre que même en changeant le port il sera forcément necessaire d'ouvrir l'accès externe au NAS dans la BOX avec une redirection de port. Que ça soit le port par défaut ou un autre ne change rien (juste peut-être la moindre visibilité dans la mesure ou le port choisi est plus "exotique", les scans de ports utilisés par les pirates potentiels se limitent en général à un nombre restreint de ports connus, mais pas toujours)

Ah oui. Et en effet c'est bien ça quand je me connecte directement dans le navigateur. Par contre ce libellé "syn6-" étrange n'apparait que quand je passe par "DS Finder" => "DSM mobile". Ça doit mettre en place une espèce de proxy/tunnel transparent sans doute. Bof, ça n'empêchera pas de dormir.

Bonjour, Tout d'abord je m'excuse d'avance de poster ici, je n'ai pas trouvé de section appropriée pour "DSM Mobile" Je m'interroge sur la signification de ce libellé "syn6-" sous le nom d'utilisateur ici. C'est sans importance bien entendu 😔

Comme c'est pour partager avec un pote (en fait c'est plutôt lui qui me partage des contenus) je ne veux pas lui imposer un achat de licence donc je pense rester sur Jellyfin. Sinon, la licence c'est uniquement côté serveur ou client aussi ?

Bon et bien ça sera Jellyfin (que je ne connaissais pas) alors et ça m'a l'air vraiment bien fichu.

Voyant ça, en précision j'ai tenté de tester si Plex pouvait m'assurer les mêmes services. A priori pour un access à distance à mon NAS il est necessaire de payer un abonnement Il faut payer pour visionner *ses* videos ? Sans déconner ?

La solution immédiate est donc de directement créer les partages nommés "multimédia" et "partages" (éviter "drive" qui pourrait devenir un jour un nom réservé) et affiner leurs droits d'accès selon les contraintes que tu souhaites leur imposer. (ou, comme dit @cadkey , un unique partage avec deux sous dossier, chacun avec des droits spécifique) mais il ne faudra pas oublier de donner au partage "maitre" un doit global (type lecture pour tout le monde, écriture désactivée) puis en dessous en ouvrant plus les droits. Et laisser "home" et "homes" avec leur configuration par défaut. Mais je persiste à m'étonner que tu indiques avoir créé *toi-même* "home" et "homes" alors qu'ils sont créés automatiquement par le système

C'est vraiment pas de chance : parmi les innombrables possibilités de choix de noms pour un dossier il a fallu tomber pile poil sur deux de ceux réservés par le système. C'est détaillé ici : https://kb.synology.com/fr-fr/DSM/help/DSM/AdminCenter/file_share_desc?version=6 Reste donc plus qu'à choisir autre chose. Au passage je me demande comment il à été possible en pratique de les *créer* alors que c'est fait automatiquement par la procédure d'installation. A noter aussi, pour lever toute ambiguïté, que "home" serait plutôt un dossier virtuel qui correspond dynamiquement au "$HOME" de l'utilisateur connecté (/home/<user>)

Ah en effet (et je le savait en plus) et j'ai zappé que @cadkey avait mentionné ce point important de contexte que c'est relatif uniquement aux certificats des noms fournis par le DDNS Synology. Mais le principal point de mon post était que je ne vois pas de risque supplémentaires face à des attaques externes à ouvrir le port 80 du moment que le port 443 est aussi (sous réserve de démonstration via un cas d'école).

Je n'ai pas compris la remarque 7 mais la 6 stipule le contraire il me semble : "Pour obtenir ou renouveler le certificat de votre domaine personnalisé, assurez-vous que le port 80 a été transmis à votre NAS. Cette limitation ne s'applique pas à Synology DDNS."

Quand je vois la pression qui est mise de plus en plus pour inciter à activer le 2FA sur nombre de services en ligne je suis inquiet d'une recrudescence de "nervouze breakdowns" lors de ce type de situations dans le grand public moins à l'aise avec la technique que nous.

Je serai intéressé par un cas d'usage pratique alors. Ce qui sera interceptible en clair par cette surveillance est uniquement le traffic des sessions venant d'utilisateurs assez stupides pour choisir explicitement de se connecter en http (car laisser la possibilité de se connecter en HTTP n'oblige personne à le faire). Les utilisateurs les plus lambda ne savent même pas de quoi il s'agit et donc utiliseront l'url (de type https donc) qu'on leur a communiquée. Et les autres n'ont aucune raison de le faire. Sinon, reste aussi la solution radicale de fermer le port 80 (sauf que ça pose un problème avec le renouvellement des certificats SSL Lets Encrypt, mais je ne suis pas sûr que ça s'applique aux domaines synology.me, myds.me etc qui utilisent peut-être un autre mécanisme pour le renouvellement... ,à tester) non, j'ai testé comme je l'ai écrit : Alors j'avoue ne pas avoir suffisament testé Ca fonctionne en effet pour une connexion via un navigateur, mais pas contre par dans par exemple l'appli mobile (DS File) Ah ben non, pas si sur finalement : j'ai activé une capture (tcpdump) sur le port 80, forcé la connexion DS File en http, et il semble bien que ça bascule en https aussi

En effet, mais comme je l'ai mentionné antérieurement, je n'ai toujours pas compris en quoi forcer https pouvait contribuer à protéger le serveur. Un potentiel attaquant ne dispose d'aucun avantage du fait que les connexions entrantes en HTTP sont accessibles. Et les utilisateurs légitimes, si par mégarde ils forcent "http:" dans l'URL (dans quel but d'ailleurs ?) , seront prévenu par une alerte de "connexion non sécurisée" dans leur navigateur. Mais *surtout*, la redirection forcée http=>https est déjà configurable dans l'interface DSM, dans la section portail de connexion : Et, même si le libellé parle de "DSM desktop", ça s'applique en pratique également aux services des applications accédées via des alias déclarés dans cette même section du panneau de configuration (je viens de vérifier). De ce fait, je ne vois pas trop l'intérêt de se compliquer à la vie à le faire via un .htaccess