[TUTO] Sécuriser les accès à son nas - DSM 6.x

[Mic13710]

@ekke Si vous avez parcouru le forum, vous avez sans doute remarqué une section intitulée "Présentation". Merci d'y déposer votre contribution.

1. Inutile puisque votre IP est fixe
2. DSM c'est l'OS et son interface. La redirection est au choix de chacun. Si vous n'exposez pas directement le NAS à l'extérieur et/ou que vous avez fait les réglages corrects au niveau parefeu, routeur et éventuellement Reverse Proxy, la redirection n'est pas indispensable. Je ne la fais pas sur mon NAS car cela me poserait des problèmes au niveau de mon Reverse Proxy à cause d'un bug de DSM.
3. On peut très bien accéder par le port 5000 (http) lorsqu'on est sur son réseau privé. Le reverse proxy permet aussi d'utiliser les ports http du NAS pour chaque application. Cette option (HSTS) est généralement plus source de problème qu'autre chose. Je ne l'ai pas activée sur mon NAS.
4. Si vous utilisez drive, il faut aussi forwarder le port 6690. Je suppose que le 80 est redirigé sur le NAS pour le renouvellement du certificat. C'est bien mais il faut alors dans le parefeu en limiter l'accès aux seules adresses de Let's Encrypt (il y en a deux que vous trouverez facilement en parcourant le forum)
5. Justement non pour le port 80 (voir §4). Supprimez la règle 80 ouvert pour tous les ports car même si elle n'est pas active, elle ne devrait pas être présente.
6. Drive n'a pas besoin d'une adresse spécifique. Il ne doit pas non plus passer par le Reverse Proxy. Il utilise seulement le ndd qui permet de rejoindre votre box via l'adresse ndd:6690 (inutile de préciser le 6690 lors du paramétrage du client puisque c'est le port par défaut de Drive). Le reverse proxy c'est pour diriger une url vers un des ports du NAS. Par exemple, pour rejoindre DSM en https avec l'adresse nas.ndd, la source est donc https - nas.ndd - port 443, et la destination http - localhost - 5000
7. Si vous utilisez le Reverse Proxy, inutile de paramétrer les adresses HTTPS. Vous n'utiliserez normalement que les ports http dans les destinations (inutile en effet de sécuriser des transactions internes au NAS)
8. Essayez de vider le cache de votre navigateur.

Vous trouverez une bonne partie des réponses dans le tuto sur le serveur DNS et pour le reverse proxy et le certificat, je vous conseille d'aller lire mon retour en page 2 du dit tuto.

A bientôt dans la section présentation 😉

 

[ekke]

@Mic13710 Merci pour ces réponses! Je reprends:

1. ok
2. ok, donc comme je compte n’utiliser que Drive, Audio Station et Video Station depuis l’extérieur, je ne redirige pas HTTP vers HTTPS.
3. Ca ne répond pas vraiment à ma question (ou alors je n'ai pas compris la réponse 😅). Quel est l'inconvénient de n'utiliser que du HTTPS, aussi bien en local que depuis internet vers NAS ?
4. "Si vous utilisez drive, il faut aussi forwarder le port 6690": sur le routeur donc? Mais quelle source / destination ? Port source 443 vers destination 6690 ?
5. Ok je supprime la règle (inactive) 80 ouvert pour tous les ports. Mais en toute logique je dois aussi supprimer la règle 80, 443 qui elle, est active (depuis Suisse, France) ? Mais du coup, plus aucune connection n'est posible depuis l'extérieur ?
6. "Drive n'a pas besoin d'une adresse spécifique. Il ne doit pas non plus passer par le Reverse Proxy" : ok, comment j'étais censé le deviner ? 😐 Rien de vu à ce sujet dans la doc... Je ne comprends pas pourquoi, mais bon soit.
7. ok, même si au final ça serait plus simple de n'utiliser qu'une seul protocole pour ne pas avoir à jongler de l'un à l'autre dans les paramètre, non ?
8. Je vais réessayer quand j'aurai revu le tout, ce soir.

Modifié le 19 mars 2019 par ekke

[Mic13710]

2. Drive n'a rien à voir avec la redirection http vers https, le 6690 est https. Ensuite, vous pouvez très bien être en HTTP en local et HTTPS de l'extérieur (il vaut mieux). Ce sont vos paramètres qui dicteront. Si vous n'ouvrez que le 443 et le 6690, vos échanges externes ne pourront être qu'en HTTPS.

3. Il n'y a pas d'inconvénient particulier. Vous rajoutez simplement une couche de sécurité supplémentaire, qui ne devrait avoir aucune utilité sur votre réseau privé, à moins que ce soit une vrai passoire.

4. Est-ce que je vous ai parlé de translation ? Vous ouvrez le 6690 que vous dirigez vers le 6690 du NAS. A ce sujet, je viens de voir que Drive utilise aussi les 5000 et 5001. Ce n'était pas le cas avec son ancienne mouture Cloud Station que j'utilise (pas encore passé à Drive et pas pressé de le faire). Restez sur le 6690 qui est un port spécifique au Cloud Synology.

5. Bien évidemment ! la règle du 80 vers la France et Suisse n'a pas de raison d'être. Comme je vous l'ai écrit, seuls les 2 ports LEncrypt doivent être autorisés dans la parefeu. Hormis celles vers LE, absolument toutes les connexions devraient être uniquement en HTTPS. ne JAMAIS passer par des ports HTTP, c'est une règle élémentaire de sécurité. S'il faut du HTTP, alors le VPN s'impose.

6. Rien de compliqué à comprendre, le service Drive du NAS passe par le 6690, comme file Station par le 7000/7001 etc... C'est très certainement dans la doc, vu que c'est un point vital pour pouvoir utiliser Drive sans passer par Quickconnect. Si ça n'y est pas, vous pouvez trouver tous les ports utilisés par Synology ici : https://www.synology.com/fr-fr/knowledgebase/DSM/tutorial/Network/What_network_ports_are_used_by_Synology_services

7. Il est totalement inutile de doubler le cryptage des échanges. Ce qui est important c'est la protection des échanges externes. Remettre une couche de cryptage du Reverse proxy (NAS) vers le paquet (NAS aussi) ne présente que l'intérêt de ralentir les échanges par un cryptage/décryptage inutile.

[Jojo (BE)]

@Almmerci pour m'avoir monté cette possibilité

[ekke]

Il y a 4 heures, Mic13710 a dit :

5. Bien évidemment ! la règle du 80 vers la France et Suisse n'a pas de raison d'être. Comme je vous l'ai écrit, seuls les 2 ports LEncrypt doivent être autorisés dans la parefeu. Hormis celles vers LE, absolument toutes les connexions devraient être uniquement en HTTPS. ne JAMAIS passer par des ports HTTP, c'est une règle élémentaire de sécurité. S'il faut du HTTP, alors le VPN s'impose.

Donc, dans le pare-feu, faut-il autoriser ou pas le 443, sachant que je ne veux pas d'accès à DSM depuis internet, mais seulement à Drive, Audio et Video ?

Si je l'autorise, à présent tout fonctionne bien (pour le reste j'ai suivi le tuto au pied de la lettre, même si je n'ai pas compris tous les concepts encore je pense). Drive, DS Audio et DS Video fonctionnent depuis mon smartphone sur réseau externe, en HTTPS (avec comme adresse pour Audio par ex.: audio.xxx.ovh:443). Mais par contre j'ai aussi accès au DSM avec mon compte admin depuis mon mobile en tapant dans le browser xxx.ovh (donc depuis internet) ! Ce n'est pas ce que je voulais.

Du coup, je désactive le 443, comme ci-dessous, mais là plus rien ne fonctionne depuis internet: "Certificat SSL du DiskStation n'est pas fiable..."

Pour info, sur le routeur de la box j'ai maintenant ceci:

 

Donc j'ai lu https://www.nas-forum.com/forum/topic/55206-tuto-dns-server/?page=2 comme tu l'as indiqué, et j'ai modifié mon certificat LE, en mettant dans "autre nom de l'objet" les nom des applis Audio et Video (audio.xxx.ovh et video.xxx.ovh):

Mais toujours erreur de certificat sur les applis DS sur le smartphone.

Pour info sur ovh, j'ai mis un CNAME sur *.xxx.ovh, afin de couvrir les applis, c'est pas correct? Il faut les mettre une par une en CNAME ? Je me dis que le wilcard fonctionne, puisque le certificat est bien créé ?

Ce qui m'étonne aussi, c'est que malgré la modification du certificat, les anciennes valeurs s'affichent toujours dans le "Pour" (cf. capture ci-dessus). La modification n'aurait pas été prise en compte?

Enfin, qu'en est-il de Drive? Je ne comprends pas pourquoi il fonctionne toujours, il n'utilise pas le certificat LE?

Modifié le 19 mars 2019 par ekke

[Mic13710]

Avant de poster, il faudrait lire ce que j'ai écrit. Je ne vous ai jamais dit de fermer le 443. Vous pouvez le restreindre géographiquement (ce que vous avez fait) mais pas le fermer sinon comment espérez vous atteindre le NAS ?

Il faudrait aussi dans le parefeu remplir les 2 règles pour les IP LE pour le renouvellement du certificat (cf : mon tuto cité plus haut). Et pour que ça fonctionne : diriger le port 80 du routeur vers le NAS (je ne sais pas pourquoi vous l'avez supprimé).

Si vous accédez à DSM de l'extérieur c'est que vous avez autorisé l'adresse ndd à accéder au port 5000 ou 5001 du NAS. Revoyez vos réglages.

Je n'utilise pas le wildcard qui est pour moi une fausse bonne idée car vous ne contrôlez pas les accès. toto.ndd ou tata.ndd ou toto.tata.ndd ou video.ndd arriveront sur votre routeur. Les CNAME individuels permettent de filtrer ce qui doit arriver sur le routeur. Mais il faut pour cela que chaque adresse soit inclue dans le SAN (cf mon tuto)

Si vous aviez lu mon tuto, vous auriez compris que les "pour" du certificat sont à configurer. Lorsque vous spécifiez un certificat comme étant par défaut, toutes les applis prendront ce certificat, ce qui ne signifie pas que le dit certificat fonctionnera avec la dite appli si son nom n'est pas couvert dans les SAN. Si vous avez supprimé le certificat Synology par défaut (ce qui n'est pas une bonne idée), vous n'avez qu'un seul certificat dans le NAS, et ce sera bien évidemment le seul utilisable puisqu'il n'y a pas le choix.

Drive a son propre schéma de cryptage qui n'a rien à voir avec le certificat LE. Pour cette raison votre url drive.ndd n'a guère d'intérêt. L'accès à drive devrait uniquement se faire par ndd:6690

[unPixel]

Citation

Je n'utilise pas le wildcard qui est pour moi une fausse bonne idée car vous ne contrôlez pas les accès. toto.ndd ou tata.ndd ou toto.tata.ndd ou video.ndd arriveront sur votre routeur. Les CNAME individuels permettent de filtrer ce qui doit arriver sur le routeur. Mais il faut pour cela que chaque adresse soit inclue dans le SAN (cf mon tuto)

Pas d'accord avec toi Mic. Tu contrôles toujours tes entrées avec un certificat Wildcard puisque tu les as créé dans le proxy inversé ou le virtual host ! Si tata.ndd.tld n'existe pas alors il ne t'amènera à rien d'autre qu'une page d'erreur 403.

De plus, le certifcat Wildcard a pour moi le gros avantage de cacher la zone DNS. J'ai des services ou je préfère qu'ils restent confidentiels aux yeux des petits curieux et ils peuvent tenter la consultation de la zone DNS sur le certificat, ils ne verront rien d'autre que le domaine principal qu'ils connaissent déjà.

Je vois aussi l'avantage que lorsque tu ouvres un nouveau domaine, tu n'as pas besoin de faire un renouvellement du certificat puisqu'il est prit en compte automatiquement.

Tu as aussi l'avantage d'avoir que deux entrées dans ta zone DNS contre autant de services que nécessaire pour un certificat SAN. Pareil, tu gagnes du temps à ne pas aller ajouter/supprimer dans ta zone DNS des domaines.

Ah et j'allais oublié, tu n'es pas limité non plus dans les domaines comme le certificat SAN de Let's Encrypt qu'on met en place de base sur un NAS Synology.

Dernière chose, plus besoin d'ouvrir le port 80 aux deux IPs des serveurs de Let's Encrypt.

Bref, je n'y vois franchement aucun inconvénient pour ma part !

Modifié le 20 mars 2019 par Zeus

[ekke]

Hum vous (puisque vous tenez au vouvoiement) perdez patience. Ce n'est pas parce que je ne comprends pas certains points que ça veut dire que je n'ai rien lu. Merci cependant d'avoir pris la peine de répondre.

J'avais fermé le 443 car dans le point 5, j'évoquais de supprimer la règle 80, 443 et vous m'avez répondu "Bien évidemment", en parlant ensuite seulement du port 80. Dans le doute (80 seulement ou 80 et 443?), et sachant que j'avais ouvert dans le pare-feu les ports pour Video Station, Audio Station et Drive, je ne voyais pas (et je ne comprends toujours pas) pourquoi garder le 443. Si Video Station, Audio Station et Drive ont leur propres ports, pourquoi garder le 443? Je ne pensais pas qu'un port devait avoir besoin qu'un autre soit activé "en parallèle" pour fonctionner. J'ai du mal à me représenter ce fonctionnement.

Citation

Il faudrait aussi dans le parefeu remplir les 2 règles pour les IP LE pour le renouvellement du certificat (cf : mon tuto cité plus haut). Et pour que ça fonctionne : diriger le port 80 du routeur vers le NAS (je ne sais pas pourquoi vous l'avez supprimé).

J'ai lu (!) qu'il est déconseillé de mettre ces 2 IP : LE ne garanti pas leur pérennité. Je préfère un renouvellement manuel tous les 3 mois. Je dirige le port 80 du routeur vers le NAS uniquement lors de ce renouvellement.

Citation

Si vous accédez à DSM de l'extérieur c'est que vous avez autorisé l'adresse ndd à accéder au port 5000 ou 5001 du NAS. Revoyez vos réglages

J'ai suivi le tuto de Fenrir: sous paramètre de DSM, on déclare les ports DSM 5000 et 5001. Je dois laisser vide ces 2 champs? AU niveau du pare-feu, je n'ai rien concernant un port 5000 en tout cas. Ou bien il faut décocher "Activer un domaine personnalisé"?

Sinon, j'ai mis des CNAME individuels à présent, sur audio.xxx.ovh, video.xxx.ovh.

Citation

Les CNAME individuels permettent de filtrer ce qui doit arriver sur le routeur. Mais il faut pour cela que chaque adresse soit inclue dans le SAN

Par adresse, vous entendez bien audio.xxx.ovh, video.xxx.ovh ? Inclu dans le SAN, ça signifie ? Dans votre tuto, vous citez 3 fois "SAN" (storage area network je suppose) mais je ne vois pas le rapport... En tout cas j'ai bien suivi votre tuto, en particulier la modification du certificat, "renseigner la rubrique "Autre nom de l’objet" " (avec "audio.xxx.ovh; video.xxx.ovh; drive.xxx.ovh" même si pour Drive visiblement ce n'étais pas la peine)

Citation

Si vous avez supprimé le certificat Synology par défaut (ce qui n'est pas une bonne idée), vous n'avez qu'un seul certificat dans le NAS, et ce sera bien évidemment le seul utilisable puisqu'il n'y a pas le choix.

Le tuto de Fenrir propose de supprimer le certificat par défaut, ce que j'ai fait.

[unPixel]

@ekke

Je me permet de te corriger, le certificat que tu as n'est pas un certificat dit Wildcard mais un certificat SAN 😉

Et les IPs des serveurs de let's Encrypt ne changent pas si souvent. pour preuve, ces dernières sont là depuis quelques années déjà.

Modifié le 20 mars 2019 par Zeus

[Mic13710]

il y a 47 minutes, ekke a dit :

pourquoi garder le 443

C'est votre choix au départ (votre premier post). Le 443 est le port HTTPS par défaut, cad que sans spécifier de port, vos requêtes sont dirigées vers ce port. Le routeur dirige ensuite les requêtes sur ce port vers le 443 du NAS. Le reverse proxy analyse la requête et la dirige vers le port affecté au service.

il y a 24 minutes, ekke a dit :

Je préfère un renouvellement manuel tous les 3 mois.

C'est vous qui voyez.

il y a 29 minutes, ekke a dit :

Ou bien il faut décocher "Activer un domaine personnalisé"?

oui

Les SAN ce sont ce qu'on appelle les "Autres noms" du certificat. Il faut faire effectivement la différence entre un certificat nominatif et un certificat Wildcard. Perso, contrairement à Zeus, je n'aime pas utiliser les wildcard. Chacun fait selon ses besoins. Ceci étant dit, rien n'empêche d'avoir un wildcard côté registar et un certificat SAN côté NAS.

il y a 42 minutes, ekke a dit :

Par adresse, vous entendez bien audio.xxx.ovh, video.xxx.ovh ?

Oui. En fait j'ai employé à tord le mot adresse. J'aurais dû plutôt dire domaine.

Pour le certificat Synology, je l'ai gardé car pour certaines applications, le changement de certificat tous les 3 mois n'est pas viable. Serveur VPN par exemple.

[ekke]

Bon, pas moyen de faire fonctionner Drive depuis internet ou appli Android. Il ne fonctionne que si je déclare un domaine personnalisé "xxx.ovh" dans les paramètres DSM (mais du coup DSM est exposé sur internet, ce que je ne veux pas).

Déjà, je ne suis pas sûr de ce qu'il faut mettre comme comme adresse dans les paramètres de connexion de Drive (Android). C'est bien "xxx.ovh:6690" ? Si je fais ça, avec HTTPS activé, j'ai une erreur de certificat pas fiable (mais au moins ça réagit). Si je mets juste xxx.ovh, ça mouline puis "échec de la connexion à DiskStation".

DS Audio et Video fonctionnent bien depuis internet, avec audio.xxx.ovh:443 et video.xxx.ovh:443

Voilà où j'en suis, auriez-vous une piste? Refaire le certificat? Je l'ai déjà modifié en suivant le tuto de Mic13710 mais je me suis peut-être pèlanté quelque part...

Dans le pare-feu, mettre la règle 443 au dessus de Drive? (idée qui m'est venue juste en voyant le screenshot maintenant)

 

 

Modifié le 26 mars 2019 par ekke

[unPixel]

Bonjour,

Je vois que tu as un domaine pour drive en drive.ndd.ovh

Dans ce cas, tu fais à l'identique d'Audio Station à la différence que tu vas ouvrir aussi le port 6690 sur le routeur.

Ça fonctionnera 😉

Par contre, tes règles pour Drive, Audio Station et Video Station dans le parefeu du NAS ne servent à rien.

Est-ce que tu as compris le principe du reverse proxy et le faite que Fenrir t'a fait ouvrir via son tuto tous les ports depuis les plages IP d'un réseau local ?

 

Modifié le 26 mars 2019 par Zeus

[ekke]

@Zeus Je forward déjà le 6690 du routeur vers le NAS.

"Est-ce que tu as compris le principe du reverse proxy et le faite que Fenrir t'a fait ouvrir via son tuto tous les ports depuis les plages IP d'un réseau local ?" > Je vais relire le tuto de Fenrir. Mais il dit pourtant d'utiliser le pare-feu pour les appli ("Ces options vous permettent, par exemple, de faire écouter les différentes applications sur des ports précis et ainsi, grâce au pare-feu, de limiter leurs accès aux seules adresses autorisées"). Puis il configure plus loin le reverse proxy, pour les applis DS.

Un simple schéma explicatif du flux internet - routeur - nas (reverse proxy/parefeu) - appli aiderait tellement!

[unPixel]

En effet, laisse ce que j'ai dit plus haut sur tes autres règles, je me suis royalement planté et j'ai dit une belle bêtise sans me relire. J'ai voulu vite te répondre car peu de temps devant moi mais je me suis pas relu 😞

Modifié le 26 mars 2019 par Zeus

[Mic13710]

@ekke Tout d'abord les deux règles du parefeu audio station et video station ne servent à rien puisque le reverse proxy vous renvoi vers le localhost et les ports correspondants aux deux applis. En effet, puisque toutes les IP privées sont autorisées en amont pour tous les ports, vous ne pouvez pas ensuite espérer bloquer quoi que ce soit puisque les règles s'appliquent de manière chronologique.

Pour Drive, si votre ndd pointe vers votre routeur (IP fixe ou DDNS), que vous avez dirigé le port 6690 vers le NAS et que le parefeu ne bloque pas ce port (attention, Drive fonctionne avec les ports 5000, 5001 et 6690 : vérifiez que c'est bien ce dernier qui est autorisé), vous devriez pouvoir vous connecter, à condition bien entendu que l'utilisateur soit autorisé à utiliser Drive. Côté client, il suffit d'indiquer le ndd, l'utilisateur et son mdp et spécifier que la liaison est SSL.

Cependant, cette liaison ne peut fonctionner qu'à partir d'internet. Elle ne peut pas fonctionner à partir de votre réseau privé, à moins que vous ayez une Freebox ou toute autre box qui autorise le loopback (renvoi de requête). Si ce n'est pas le cas, vous ne pouvez pas mettre comme adresse de connexion votre ndd puisque votre réseau privé est incapable de la résoudre. Il faut alors changer la connexion en remplaçant le ndd par l'ip privée du NAS. Ce qui est bien entendu fastidieux. Pour résoudre ce problème, il faut utiliser le serveur DNS et y créer une zone pour le réseau privé. C'est un peu compliqué, mais vous avez un excellent tuto de Fenrir (encore lui) qui explique comment faire.

[unPixel]

Citation

Tout d'abord les deux règles du parefeu audio station et video station ne servent à rien puisque le reverse proxy vous renvoi vers le localhost et les ports correspondants aux deux applis. En effet, puisque toutes les IP privées sont autorisées en amont pour tous les ports, vous ne pouvez pas ensuite espérer bloquer quoi que ce soit puisque les règles s'appliquent de manière chronologique.

Merci de me remettre le cerveau en place. J'avais bien répondu puis j'étais revenu en arrière pour finalement me rendre compte après ton post que j'avais raison 🤣

[ekke]

Il y a 20 heures, Mic13710 a dit :

Tout d'abord les deux règles du parefeu audio station et video station ne servent à rien puisque le reverse proxy vous renvoi vers le localhost et les ports correspondants aux deux applis. En effet, puisque toutes les IP privées sont autorisées en amont pour tous les ports, vous ne pouvez pas ensuite espérer bloquer quoi que ce soit puisque les règles s'appliquent de manière chronologique

Ok merci, c'est enlevé et compris.

Il y a 20 heures, Mic13710 a dit :

Pour Drive, si votre ndd pointe vers votre routeur (IP fixe ou DDNS), que vous avez dirigé le port 6690 vers le NAS et que le parefeu ne bloque pas ce port (attention, Drive fonctionne avec les ports 5000, 5001 et 6690 : vérifiez que c'est bien ce dernier qui est autorisé), vous devriez pouvoir vous connecter, à condition bien entendu que l'utilisateur soit autorisé à utiliser Drive. Côté client, il suffit d'indiquer le ndd, l'utilisateur et son mdp et spécifier que la liaison est SSL.

J'ai bien fait tout ça, et je suis en IP fixe. Le user est ok aussi. Drive marche sur le smartphone mais impossible de configurer le client PC (sur un PC externe à mon réseau, depuis internet): "Connection failed".

Je me demande si il y a quelque chose qui ne fonctionne pas au niveau du pare-feu... Vu que j'ai laissé le domaine personnalisé (xxx.ovh) actif pour que DS Audio, Video et Drive sur smartphone fonctionnent, j'ai voulu bloquer l'accès à DSM depuis l'extérieur. J'ai mis une règle sur les ports 5000, 5001: "deny" pour source IP "All". Pourtant j'ai encore accès au DSM depuis l'extérieur quand je mets xxx.ovh dans le browser...

Modifié le 27 mars 2019 par ekke

[Mic13710]

Selon d'où vous vous connectez (réseau d'entreprise qui filtre les E/S) il est possible que le port 6690 soit bloqué. Je ne connais pas le client Drive (j'utilise encore Cloud Station). 6690 est le port par défaut et l'unique port pour CS. Mais Drive utilise aussi les 5000 et 5001. Puisque vous avez mis un ndd sur drive, essayez en utilisant celui-ci sur le 5001. N'oubliez pas d'indiquer les ports dans le portail des applications. Mais si le 6690 est bloqué, il y a fort à parier que le 5001 le sera aussi.

Il y a 1 heure, ekke a dit :

J'ai mis une règle sur les ports 5000, 5001: "deny" pour source IP "All". Pourtant j'ai encore accès au DSM depuis l'extérieur quand je mets xxx.ovh dans le browser...

Activez Web Station pour que les requêtes soient orientées vers votre serveur Web. Il vous donnera une erreur 502 si le serveur Apache n'est pas installé mais vous ne serez pas orienté vers DSM.

[weyb]

bonjour,

 

j'ai un Syno DS414 avec kodi qui li(sai)t mes musiques et mes films en partage SMB.

Comme j'ai appliqué certaines de vos règles en début de semaine  - notamment sur les users et mdp, je réponds ici plutôt que créer un nv post...

Voici ce que j'ai fait :

- j'ai créé un nv user de type admin avec un mdp fort

- j'ai désactivé "admin" et NFS

- et comme j'avais a minima l'appli de synchro vers un cloud "cloudsync" qui ne marchait plus, j'ai ré-activé "admin" mais avec un mdp fort

et depuis kodi n'accède plus en SMB sur mon NAS 😞, j'ai le message "operation not permitted"

(- j'ai ré-activé NFS sur mes partages existants, mais côté kodi je ne m'en sors pas +, je n'arrive pas à voir les sous-répertoires précis contenant les medias, et puis ça marchait avant en SMB, donc je cherche à refaire fonctionner l'accès en SMB...)

le forum kodi m'a dit de créer un user "kodi" et de lui donner les droits, ce que j'ai fait ce matin (enfin, je pense !), mais ca marche pas + (cf post https://www.homecinema-fr.com/forum/post179874276.html#p179874276)

 

d'avance un grand merci pour m'éclairer et essayer de comprendre d'où vient le pb ca rje n'accède plus à rien... 😞

 

cordt

[unPixel]

Bonjour,

Peux-tu faire une capture d'écran de ton partage NFS stp. Merci

[weyb]

comme ca ca marche ???

https://www.casimages.com/i/19033010283788315.png

 

je ne sais pas incruster une image dans un forum...

[unPixel]

Modifie et fais comme moi :

 

Modifié le 30 mars 2019 par Zeus

[weyb]

ca c'est pour le NFS ?

j'ai fait ça sur le partage "music" du NAS, mais côté kodi, je ne peux pas sélectionner "/volume1/music", je me retrouve avec la source "nfs://192.168.0.2"

😞

mais pour le SMB ?

Modifié le 30 mars 2019 par weyb
coquille

[unPixel]

Je ne fais pas de partage SMB avec Kodi mais NFS. Plus simple et plus rapide et sans demande d'authentification.

Ouvre ton topic pour demander de l'aide si tu veux 😉

 

[weyb]

j'ai réussi à retrouver le ss-rep "music" via SMB en faisant dans kodi "ajouter un emplacement réseau" + @IP + user/passwd, donc je vais essayer de continuer comme ça...

 

Merci en tous cas !!!