Mic13710

Avez-vous consulté la base connaissance Synology ? https://kb.synology.com/fr-fr/DSM/tutorial/How_to_access_files_on_Synology_NAS_with_WebDAV

C'est normal qu'en désactivant la dernière règle, ça fonctionne puisque vous autoriser tout. Votre NAS est open bar. Tant qu'une règle n'est pas remplie, on passe à la suivante. Si rien ne bloque, tout passe. Ensuite, vous ne pouvez pas accéder à DSM de l'extérieur puisqu'aucune règle ne l'autorise. La seule règle qui fonctionne c'est le serveur FTP. Vous n'avez pas rajouté video station comme je vous l'ai dit et si vous voulez d'autres applications, il va falloir aussi les autoriser. Vous ne parlez pas non plus de votre routeur où vous devez rediriger les ports des différentes applications vers le NAS. Si ce n'est pas fait, il y a aucune chance pour que vous puissiez atteindre le NAS.

Ce qui suppose que vous voulez l'utiliser de l'extérieur. Avant d'exposer votre NAS sur le web, je vous conseille vivement de commencer par sécuriser votre NAS. Un parefeu désactivé c'est la porte du NAS grande ouverte. Il y a un tuto sur la sécurisation dans la partie Tutoriels. Pour votre problème, est-ce que le ou les utilisateurs sont autorisés à utiliser Webdav ?

Si vous ne l'avez pas encore remarqué, ce forum comporte des rubriques et il y a une description pour chacune d'elle. "Nos membres racontent" c'est pour des anecdotes, pas pour poser des questions. Je déplace. Merci de faire attention où vous postez vos demandes.

Est-ce que le parefeu autorise webdav ?

La première règle est inutile et peut être supprimée puisqu'elle est couverte par la deuxième. La troisième ne sert à rien car le serveur DLNA ne fonctionne que dans le périmètre du réseau privé. Si vous voulez utiliser DSVideo, il faut modifier la règle en ouvrant le port https de video station. Attention, Video Station et son application nomade DSVideo ont été supprimés de DSM depuis la version 7.2.2.

@storlok, merci pour le retour. Malheureusement, en faisant cela vous inhibez la sécurité des échanges avec le NAS et tout ça parce que votre version de DSM n'est pas à jour. Là je ne suis pas d'accord. De nombreuses failles de sécurité ont été corrigées depuis votre version de DSM. Je vous encourage fortement à faire ces mises à jour qui en plus vous apportent de nouvelles fonctionnalités. Et vous pourrez ainsi passer à SMB3 et réactiver la signature des échanges pour vos lecteurs mappés. Le site d'archivage dont vous trouverez le lien dans un de mes messages plus haut est à nouveau opérationnel. Plus d'excuse pour ne pas faire ces mises à jour !

Tout à fait d'accord. J'ose espérer qu'on peut désactiver le bazar et le faire simplement. Où alors c'est encore un truc que nous impose Synology comme ils en ont pris l'habitude depuis quelques temps.

Genre une tâche programmée dans votre agenda favori 😉

6 ans c'est déjà bien au delà des standards donnés par les constructeurs qui sont plutôt autour des 2-3 ans. Il ne faut pas se fier aux tests effectués par l'UPS. Ils ne durent que quelques secondes ce qui ne sollicitent pas la batterie suffisamment longtemps pour connaître son état réel. Rien ne vaut un test périodique (tous les 6 mois ou au moins 1 fois par an) sur une charge significative et connue comme par exemple une lampe halogène, l'UPS déconnecté de la charge habituelle (NAS, routeur, PC, switch, etc..). On vérifie l'autonomie en fonction de la puissance de la charge et celle de l'UPS et du temps de fonctionnement à pleine charge donné par le constructeur. Ca ne garantit pas que l'UPS tiendra la charge à la prochaine coupure (la batterie peut lâcher à tout moment), mais au moins on vérifie que la batterie et l'UPS sont OK au moment du test. Et si la batterie est limite lors du test, mieux vaut alors la changer à titre préventif.

Attention avec la version de Synology Assistant. Les NAS avec des versions de DSM inférieures à 6.2.3 ne peuvent être détectés que jusqu'à la version 7.0-50029. Note de version pour la 7.0.1-50044 : Vous pouvez retrouver les anciennes versions ici : https://archive.synology.com/download/Utility/Assistant

Avant d'arriver à remplir votre volume, vous avez forcément eu pas mal d'avertissements sur l'état de remplissage des disques. Ca ne date pas d'hier. DSM peine à gérer un groupe avec aucune capacité disponible. Il eut fallu remplacer vos disques par des plus gros bien avant ce point critique. Il y a quelques possibilités pour récupérer vos données. Voici une kb Synology pour vous aider : https://kb.synology.com/fr-fr/DSM/tutorial/How_to_fix_hard_drive_failure_and_retrieve_the_data_from_your_hard_drives Pour la solution via un PC (https://kb.synology.com/fr-fr/DSM/tutorial/How_can_I_recover_data_from_my_DiskStation_using_a_PC), le disque ne pourra pas être lu à partir d'un port USB. Il faut un PC avec des connecteurs SATA dispos.

Bonjour @Miniboy, soyez le bienvenu sur le forum. Pour bien commencer avec votre NAS, je vous conseille d'aller faire un tour dans la section des tutoriels où vous trouverez un tuto qui date un peu mais toujours d'actualité sur comment débuter avec un NAS et un autre très important sur la sécurisation de votre NAS.

A moins que cela ait changé (Synology modifie souvent et malheureusement pas toujours dans le bon sens...), on peut choisir (case à décocher) la non création d'un dossier SynologyDrive dans le dossier client. Vous n'avez sans doute pas vu cette option (cochée par défaut) lors de la création du dossier client ce qui explique l'ajout du dossier dans votre dossier d'origine. Si vous voulez en changer, vous supprimez la synchro, supprimez le dossier SynologyDrive et vous paramétrez un nouveau client en prenant soin cette fois de décocher la case.

Il faut que chaque service soit associé à son certificat dans les paramètres des certificats.

Que vient faire ce message dans C2 Storage ? Je déplace. Faites attention aux rubriques dans lesquelles vous postez. De plus la mise en page rend difficile sa compréhension. Prière de remplacer vos photos par de vraies captures d'écran. Si vous savez accéder au NAS en SSH, que donne la commande suivante : cat /proc/mdstat

Oui mais le renouvellement est automatique via le script acme.sh, congés ou pas ! Donc, il ne devrait pas y avoir à se soucier des dates des certificats. Visiblement, non. Vous pouvez forcer le renouvellement d'un certificat avec la commande : docker exec Acme sh -c "acme.sh --issue --force --keylength 4096 -d 'ndd' -d '*.ndd' --dns dns_ovh --dnssleep 300" corriger dns_ovh en fonction de votre registrar.

J'ai un peu de mal à comprendre comment des certificats à jour la veille ne le sont plus le lendemain.... Je ne suis pas sûr que le déploiement puisse se faire avec des certificats obsolètes.

Si vous supprimez tout, qu'est que vous voulez dire, docker, le dossier acme et les certificats pour repartir de zéro ? C'est une option.

Cette instruction ne fait que re-lancer le déploiement des certificats du dossier acme en fonction des paramètres de vos certificats dans le menu du même nom (quel certificat pour quelle application). Elle ne devrait pas toucher les certificats existants, sauf peut-être si un certificat n'est pas utilisé par DSM (ce n'est que supposition). J'ai moi aussi 2 certificats et le script ci-dessus fait bien le déploiement des deux lorsque je le lance. Il m'est arrivé que ça ne se passe pas comme prévu et il faut alors relancer le script. Si vos certificats sont bien existants et valides dans acme et qu'ils sont bien dispatchés sur vos différentes applis, alors il ne devrait pas y avoir de problème.

Je suis désolé, le terme n'était pas approprié. En tout cas, je ne l'avais pas écrit dans cette intention. Je viens de corriger. Ceci étant dit, je rejoins tout à fait ce que vient d'écrire Lelolo : poser une question sur le forum et venir près de 2 ans plus tard pour consulter les réponses sans même adresser un merci aux intervenants qui ont pris de leur temps pour tenter de vous aider .... chacun interprétera ça comme il l'entend, moi j'appelle ça du FdG 🤫

Dans le planificateur de tâche, vous créez une tâche en root pour le déploiement des certificats : docker exec Acme sh -c "acme.sh --deploy -d 'ndd1' --deploy-hook synology_dsm" # Pause de 2 secondes pour permettre à la première commande de se terminer sleep 2 docker exec Acme sh -c "acme.sh --deploy -d 'ndd2' --deploy-hook synology_dsm" etc, si vous en avez d'autres. Vous pouvez garder cette tâche dans le planificateur sans l'activer pour pouvoir la relancer si le problème se reproduit plus tard.

Pour de la sauvegarde, le JBOD me semble le plus adapté. Gardez à l'esprit que la perte d'un disque signifie la perte d'une grande partie des données, voire toutes. Vous pouvez aussi opter pour du Raid 0. Les données sont alors réparties sur les deux disques. Dans ce cas, la perte d'un disque = perte de toutes les données. Dans le gestionnaire de stockage, vous supprimez le volume et le groupe existant puis vous recréez un groupe en JBOD (ou RAID 0) et un nouveau volume.

C'est encore et toujours le même problème. Votre box est sur un réseau différent de celui de vos bornes et il n'y a pas de passerelles entre les deux. Pour que vos équipements en Wifi puissent "voir" le NAS sur la box et vice versa, il faut que vos bornes soient en mode AP. C'est alors le serveur DHCP de la box qui attribue les IP qui sont toutes sur la même plage. Si le mode AP n'existe pas, il faut réactiver le wifi de la box et mettre les Xiomi en répéteur. Il faut dans ce cas qu'au moins une des bornes soit à proximité ou du moins à bonne portée de la box pour recevoir un signal suffisant et avec un minimum de pertes. Encore faut il trouver comment faire sur le Xiomi car de ce que j'ai pu lire, ce n'est pas évident et pas clairement documenté. Je ne peux pas plus vous aider. A vous de trouver comment faire avec vos bornes.

@total_noob_user j'ai déverrouillé le tuto. Cependant, sachez que vous ne recevrez aucune réponse de son auteur.