Mic13710

Et je n'utilise pas le tuto non plus. J'applique directement le tuto github https://github.com/acmesh-official/acme.sh/wiki/Synology-NAS-Guide Intéressante ton approche concernant le nom du certificat. Ca aurait du sens car je pense avoir eu des renouvellements avec probablement cette modification et les certificats se sont bien renouvelés au bon endroit.

Chez moi pas de dossier Certs sous le volume 1. Mais je n'utilise pas le script, ceci explique peut-être cela. Le nom du certificate se trouve dans le fichier de conf du certificat : /usr/local/share/acme.sh/ndd/ndd.conf Mais en vérifiant sur mon 214, je m’aperçois que cette variable est maintenant utilisée par acme.sh SAVED_SYNO_Certificate='__ACME_BASE64__START_xxxxxxxxxxxxxxxxxxxxxx__ACME_BASE64__END_' ce qui fait que le nom du certificat a disparu. Il va falloir que je creuse le pourquoi et surtout quelle conséquence sur le renouvellement car j'ai deux certificats et si le nom n'est pas spécifié, ça risque d'être compliqué.

Et vu les nombreux retours pas très convaincants et les changements importants au niveau de certains paquets, ça ne fait pas vraiment envie. Je ne suis pas pressé d'y aller, surtout que DSM6 fonctionne très bien, il n'y a aucune raison valable de me faire du mal. Il faudra bien pourtant s'y résoudre un jour, mais seulement après quelques versions et correctifs et surtout que les essuyeurs de plâtre aient fini leur boulot 😉

@mickaeulkaeul Pour cela, il faut définir un profil de contrôle qui limite l'accès aux seules IP privées (on peut en réduire la voilure aux seules plages réellement utilisées) et l'appliquer dans la règle. Par ailleurs, il est inutile de remettre une couche ssl sur la redirection. Vous pouvez très bien mettre du http sur la redirection avec un port http (ici le 5000). Enfin, inutile aussi de donner l'ip du NAS sur la destination puisqu'il s'agit de l'hôte local. Vous remplacez simplement l'IP par "localhost" (sans les guillemets bien entendu).

@mickaeulkaeul Il serait souhaitable de mettre à jour votre signature : il y a bien longtemps que la méthode de Fred a disparue et son site aussi d'ailleurs 🤫 Il n'y a aucune contrainte à conserver le certificat Synology. C'est ce que je fais pour tous les NAS dont je m'occupe. J'utilise ce certificat pour le VPN pour ne pas être bloqué lors des renouvellements des certificats LE. Par contre, il faut bien préciser dans le fichier de conf quel certificat est concerné par le renouvellement par la commande : $ export SYNO_Certificate="Nom_du_certificat" Si vous avez suivi le tuto, vous devriez avoir une ligne correspondante dans votre fichier de conf. Il s'agit bien du nom du certificat tel que vous l'avez donné et qui apparait dans la page des certificats et non du ndd auquel il s'applique. Ceci implique qu'il ne faut pas changer le nom du certificat dans DSM, ou si vous le faites, il faut aussi corriger le fichier de conf, sinon le renouvellement ne pourra pas se faire.

Probablement. Sauf pour l'UPS, je n'ai jamais utilisé les ports USB des NAS que ce soit pour des disques externes, des dongles RFXCom, Wifi ou autres. Comme de toute manière Synology a abandonné le support des périphériques USB, ça laisse peu d'espace d'utilisation. Aussi pour mon utilisation perso, que ce soit du USB1, 2 ou 3, ou ..., n'a pas d'importance. Ce ne sont que des ports qui ne me servent pas à grand chose.

Pas possible. On ne peut pas revenir à une version inférieure. Si vous voulez réactiver vos périphériques, vous avez ce tuto : Sans garantie que cela fonctionne pour vous

Puisque vous êtes joueur, et seulement une fois que vos données ont été sauvegardées, vous pouvez essayer cette procédure. Sans garantie qu'elle fonctionne et sans garantie non plus que les commandes soient encore possibles sur nos NAS car Synology brident de plus en plus DSM avec certaines commandes devenues inaccessibles en ssh. https://superuser.com/questions/834100/shrink-raid-by-removing-a-disk

On est bon pour un update 3 A croire que ça n'affectait pas grand monde. Je n'ai pas vu passer de post sur des problèmes d'identification sur Quickconnect. A moins qu'à force de marteler qu'il y a mieux à faire que de passer par QC, peu de monde au final l'utilise.

Si c'est sur le 710+ que vous tentez de faire tourner ce tuto, il y a peu de chance qu'il puisse fonctionner car votre version de DSM ne gère pas les certificats de la même manière que DSM6. Il vous faut passer par la méthode intégrée dans DSM.

Tout à fait Brunchto. C'est un risque dans un réseau d'entreprise, beaucoup moins évident dans un réseau domestique. Et même en cas d'usurpation d'identité, il faut encore avoir les identifiants de connexion pour pouvoir entrer dans le NAS. Disons que de limiter la plage de connexion permet de faire une ségrégation à l'intérieur d'un réseau sans toutefois offrir un isolement inviolable par rapport aux autres IP de la plage DHCP.

Il n'est pas possible pour un adressage direct (192.168.x.x) de définir une plage d'adresse pour un dossier partagé dans DSM. Si vous utilisez le proxy inversé pour atteindre ces dossiers, vous pouvez alors créer un profil de contrôle d'accès qui est limité à la plage que vous voulez, puis vous appliquez ce profil au ndd associé à chaque dossier concerné. Mais cela ne bloquera pas les accès directs, uniquement ceux via le proxy inversé. Comme le dit CyberFr, c'est au niveau du parefeu que vous pouvez bloquer tout accès à une plage d'adresses. Par exemple, vous pouvez très bien limiter l'accès au NAS aux seules IP de la plage de votre exemple et en réservant dans le serveur DHCP de votre routeur les IP des appareils autorisés dans la dite plage, seuls ces appareils auront accès au NAS.

Le disque d'un nas monobaie est du linux simple en ext4. Il peut être lu directement avec un simple boitier USB. Pour pouvoir lire des fichiers EXT4 sur un MAC, vous trouverez toutes les solutions sur la toile (je ne connais pas les MAC)

Votre disque comporte trois partitions : 1 système (DSM), 1 swap et 1 données Si DSM ne tient pas, il y a de forte chance pour que la partition système soit défectueuse. Vous pouvez aussi regarder du côté de la batterie interne qui peut être HS mais qui normalement n'affecte pas le système.

Si le test bloque, il y a de grande chance que le disque soit proche de sa fin de vie. Les notifications confirment qu'il y a un problème. Le gestionnaire de stockage peut très bien indiquer que le groupe est sain. Ce n'est absolument pas une garantie que le disque n'a pas de souci. A mon avis, il est préférable de mettre vos sauvegardes à jour et de procéder au remplacement du disque.

Il faut lire la phrase jusqu'au bout ! J'ai un distributeur de torgnoles en promo, si ça peut aider.

Je pense qu'il s'agit d'un problème de disque, plus précisément d'un souci de partition système. Il faudrait faire un test smart étendu du disque.

C'est la raison principale qui me fait garder la version serveur 2.xx.. Ainsi, DSCloud est toujours actif et je peux utiliser mes fichiers offline, essentiellement mon fichier Keepass que j'utilise avec Keepass2Android version offline. Je vais attendre que Synology revoient la copie de leur application mobile car vus tous les retours négatifs ce serait étonnant qu'ils ne fassent pas machine arrière. L'ennui c'est que le passage vers DSM7 oblige à passer à la dernière version de Drive. Raison de plus pour moi pour rester sous DSM6 encore quelques temps.

@StéphanH bonne remarque. Seul @rodo37 est en mesure d'intégrer de nouvelles sections.

DS Drive n'existe pas. DS Cloud est remplacé par Synology Drive (mobile) https://play.google.com/store/apps/details?id=com.synology.dsdrive&hl=fr Néanmoins, cette application ne fait pas l'unanimité (voir les commentaires dans google play). A titre personnel, je viens de l'installer et je n'ai pas encore réussi à me connecter. ontrairement aux commentaires, ce n'est pas DSM7 qui a abandonné DS Cloud mais la dernière version de Drive (V3....) qui n'est plus compatible, tout comme elle n'est pas compatible avec les anciens clients (V2....)

Pas possible. Pour faire simple, un lecteur réseau c'est sur le LAN. Si vous voulez avoir des lecteurs locaux à distance, vous avez deux solutions : passer par un serveur VPN local (celui du NAS fait l'affaire) passer par Webdav

@YvesBertle parefeu applique les règles à la suite. La vérification s'arrête lorsqu'une règle s'applique. S'il rencontre une règle qui stoppe tout, il n'ira pas plus loin puisque par définition cette règle s'applique dans tous les cas. Ce qui suit ne sera pas testé. Si vous voulez ajouter une règle, il faut la placer avant celle du refus. Inutile d'effacer la règle du refus, vous pouvez déplacer les règles directement dans le parefeu.

Sauf s'il s'agit de fichiers qui sont modifiés dans le cadre d'une utilisation très spécifique, c'est effectivement une très mauvaise utilisation de Drive. C'est bien comme cela que je l'utilise aussi Toutefois, le btrfs permet d'élargir le type de fichiers à gérer car le dossier caché fonctionne en mode snapshot, ce qui réduit considérablement la taille du dit dossier. J'ai laissé le versionning à 32 car l'impact est très faible sur le dossier caché, surtout en btrfs. Quand on y met que ce qui doit s'y trouver, la taille du dossier est tout à fait raisonnable et surtout très très loin de représenter 32 fois l'ensemble des fichiers gérés par le cloud. Pour ma part, il n'est guère plus gros que l'ensemble des données tout simplement parce que le nombre de fichiers que je modifie régulièrement est très faible comparé au total des fichiers. En plus de cela, je fais un snapshot journalier des données qui est lui aussi sur le nombre de versions par défaut : 256. La place occupée est totalement négligeable. Et bien entendu, il y a les sauvegardes hebdos. Probablement pas car comme je l'ai écrit plus haut, le dossier garde aussi les fichiers qui ont été supprimés. C'est un des avantages du Cloud que de pouvoir restaurer un fichier supprimé par erreur, et heureusement. Aussi, la taille du dossier a peu de chance de représenter la totalité des fichiers X fois le versionning, surtout que ce dossier est compressé.

C'est surtout que le dossier Cloudstation contient tous les fichiers passés et présents du Cloud. Même si un fichier a été supprimé, il existe toujours dans @cloudstation, d'où la taille qui peut paraître excessive mais qui n'est que le reflet de l'historique de l'utilisation qui en est faite.

Quel que soit le nombre de NAS, tant qu'il n'y a pas de vrai sauvegarde sur un DD externe, un autre NAS, un serveur externe, bref, un autre support, le risque de perte de données est réel. Il faut toujours avoir à l'esprit que la sauvegarde a autant d'importance que les données source. Il ne faut surtout pas croire qu'un NAS est la solution de stockage ultime et infaillible. Certains y ont cru et pleurent leurs chères données perdues à tout jamais.