Fenrir

Pour comparer à ton Mac, c'est toi qui déverrouille ton disque lors du démarrage, donc tu peux faire la même chose sur le syno. Si tu laisses ton nas allumé h24 (ce qui est recommandé), ça ne devrait pas être contraignant => Comme ça, en cas de vol de ton nas, comme il sera nécessairement coupé du courant, le partage ne sera pas exploitable car chiffré.

Tu trouveras plus de détails sur le forum, ta question a déjà été traitée des centaines de fois (voir plus), mais pour te donner un début de réponse : Dans la plupart des cas, c'est la TV le facteur limitant, si ta TV lit tous les formats vidéo et audio que tu veux utiliser, le nas se contentera d'envoyer le fichier, donc même un petit modèle fera l'affaire, par contre, si certains formats ne sont pas pris en charge, alors le nas va essayer de convertir le fichier => ça consomme bcp de ressource, d'où l’existence des modèles Play (nb : le nas ne pourra pas faire la conversion si la piste son est en DTS).

Tu n'aurai pas changé le port par hasard ? Essaye https://adresse.ip.du.nas:5001 ou tout autre port que tu aurais peut être configuré. Autre possibilité, mais j'en doute, le firewall mal réglé. Tu as encore accès en ssh ?

Pas nécessairement, moi je ne reçois des mails que pour les MP, par contre lorsque je me connecte sur le forum la cloche en haut à droite affiche les messages avec des réponses. Pour ton problème, il peut avoir plusieurs causes (cache dns, bande passante saturée, panne serveur, ...) mais comme un reboot (un peut brutal :s) semble avoir réglé le souci, je penche pour un verrou ou un cache.

Je pense que dans les logs tu avais un message (synoupdate.log). Pour ton nas, dans le pire des cas tu as "juste" à réinstaller DSM (tu vas perdre la conf et les appli, mais pas les données). Tu peux utiliser Synology Assistant pour le retrouver et le réinstaller (éventuellement après un double reset).

Essaye avec Synology Assistant, si ton nas n'est pas détecté, il va probablement falloir le forcer à rebooter.

C'est peut être tout simplement un souci de cache avec ton navigateur. Tu as vérifié ?

Les photo sont bien dans le partage photo ? Si tu créés un album via l'interface, il apparait ? Si tu ajoutes une photo via l'interface, elle apparait ? As-tu essayé de supprimer l'application et de la réinstaller ? Tu peux aussi tenter de mettre ton nas à jour. Si tu penses que c'est la base qui a un problème, tu peux tenter ceci (nb : ça peut affecter d'autres applications comme VideoStation) : mv /volume1/@database/pgsql /volume1/@database/pgsql-bk reboot

Si le paquet est propre, oui c'est possible. Par contre il peut rester des traces des paquets installés avec ipkg, mais ça ne devrait pas être gênant, juste pas propre.

Le principe du chroot est d'isoler "partiellement" des process du système hôte, donc un chroot est sans danger pour l'hôte (hors failles ou chroot mal monté). Dans ton lien, on voit clairement que c'est le paquet qui a créé un problème, pas le contenu du chroot. Pour ma part, avant l'introduction de Docker sur mes nas, j'utilisais des chroot "fait à la main" (sans passer par un paquet tout fait) et je n'ai jamais eu de problèmes. Donc ta question devrait plutôt être : le paquet debian-chroot est il correctement créé ? Ci dessous, la mini doc que j'avais fait à l'époque : http://www.nas-forum.com/forum/topic/46705-debian-chroot-ds214play/?do=findComment&comment=1319267906

Je ne parle pas de la sécurité du serveur, mais du client.

Non Je reformule de manière plus explicite. Les trames n'étant pas signées (il ne s'agit même pas de chiffrement ici), un "attaquant" peut facilement se faire passer pour ton serveur (même sans faire de MitM) et t'envoyer des fausses réponses contenant, par exemple, une charge virale (ou n'importe quoi en fait, cookie traceur, image pédopornonazie, redirection vers un site tiers ...). En chiffrant, en plus de protéger le contenu des échanges, les paquets sont signés, donc il n'est plus possible de falsifier les réponses (c'est l'intégrité ci dessous). Dit autrement, il ne faut JAMAIS se connecter à une ressource non chiffrée si on passe par un réseau non fiable. Un site comme ce forum qui ne propose du chiffrement que sur la page de connexion ne devrait pas être consulté depuis un hotspot par exemple.

@Einsteinium : je n'ai pas testé, mais si le dossier est monté "après" le démarrage de PhotoStation, ça ne va pas créer de souci au niveau indexation et droits dans l'appli ?

Je fais parti de ceux qui recommandent de ne pas changer les ports par défaut quand c'est possible car ça n'apporte presque rien coté sécurité (c'est même plutôt le contraire dans certains cas). Dans l'absolu, laisser le port SSH ouvert à la planète n'a pour seule conséquence que de remplir les logs SI ET SEULEMENT SI le service est correctement configuré : authentification uniquement par clef Ed25519 ou RSA (>= 4096) root interdit, même avec clef les utilisateurs autorisés ne doivent pas être dans sudo les ciphers ssh doivent être limités ... Dans le cas des Synology, ce n'est pas possible de le configurer correctement => pas de ssh ouvert depuis Internet pour synology Je te donne un exemple, si tu te connectes depuis un réseau non sécurisé à ton nas en http (par exemple un hotspot, le réseau ouvert des voisins, en 3G/4G) => toutes les personnes à portée peuvent connaitre les login/pass utilisés, modifier les requêtes, modifier les réponses (et t'envoyer ce qui veulent). Idem pour le FTP ou tout autre protocole d'échange non signé. Pour info, les "pirates" (en pratique il s'agit de programmes 100% automatisé) passent par différents "intermédiaires" pour masquer leurs traces et faire croire qu'ils sont en France, il peut s'agir de proxy, de vpn, de ... mais en pratique c'est rarement utilisé car il est nettement plus simple de se servir de machines infectés dans différents pays (botnet).

Un attribut commentaire je crois

Je pense que tu as créé ta règle après la dernière qui bloque tout. Pour le certificat, il faut le configurer par défaut pour les différentes applications

Seulement pour certains paquets (ils sont proposés quand tu fait un hyperbackup)

C'était pour éviter de se faire infecter (ou sur infecter ) par Wannacry. Pas de SMB => pas de propagation

En premier lieu, cet article commence à dater. Il aurait été intéressant que tu indiques ton point de vu sur l'article, à défaut voici le mien. En version courte : sécurité : si votre modèle de menace se limite aux scripts-kiddies ou aux bot, un Synology correctement configuré (et sauvegardé !!!) sera bien largement assez sécurisé pour faire de l'auto hébergement en tout cas très probablement plus qu'un système monté à la main par un non spécialiste si votre modèle de menace inclut des états ou des groupes criminels, vous vous trompez de débat simplicité : même en étant spécialiste de l'auto hébergement, une personne seule ne pourra pas rivaliser fonctionnalités : si le syno ne suffit pas, rien ne vous empêche de lui adjoindre un compagnon (un rpi par exemple), il se sentira moins seul --- En version longue L'article se veut assez objectif dans l'ensemble (il faut lire au delà de ton extrait), mais certains points me semblent exagérés, d'autres sont faux. Vrai mais Synology fait plutôt parti des bons élèves sur ce point. Vrai mais les utilisateurs de distrib Linux ont aussi du attendre que les éditeurs fassent de même, certes ça peut aller très vite (quelques heures pour HeartBleed), mais ça peut aussi prendre bien plus de temps => dans un cas comme dans l'autre, sauf à être à la source, on reste dépendant d'un ou plusieurs intermédiaires => c'est une histoire de confiance Faux : en premier lieu rien ne nous oblige à rendre le NAS accessible depuis n'importe où, de plus on en contrôle les accès physique et logiques (certains pourront dire que le nas peut contenir une backdoor ou envoyer des données sur le net, un bon firewall est c'est réglé dans 99.999% des cas) enfin le jour où votre hébergeur en ligne dira - "pour accéder à vos nos c'est 10€ par Go (ou mois) maintenant" - vous ferez quoi ? <spoil>certains l'on déjà fait (amazon, google, apple, ...)</spoil> Je ne suis pas d'accord. Pour les fonctionnalités, la charge de travail pour arriver à faire un système approchant ce qui est intégré à un NAS est tout simplement inatteignable pour un particulier (même très compétent). Il ne faut pas oublier qu'en face c'est une entreprise avec des dizaines/centaines de développeurs, administrateurs, graphistes, ... Un truc tout bête, mettre en place un équivalent à SHR est déjà hors de portée de la quasi totalités des utilisateurs. Faire en sorte que toutes les applications soient en SSO est encore plus complexe. Pour l'aspect sécurité, j'aurai plus confiance en un nas pas mis à jour depuis 5 ans qu'en un serveur applicatif monté la veille par un amateur. Installer un OS de manière sécurisée est relativement simple, il suffit de partir sur une bonne base (OpenBSD par exemple, ou Debian ou encore CentOS), mais à dès qu'on commence à y ajouter des applications, à modifier la configuration (qui a dit 777) et à l'ouvrir au monde extérieur, les choses se gâtent. Sécuriser correctement (je ne parle même pas de NSAproof, juste d'anti scripts kiddies) un système et ses applications c'est un métier à plein temps qui nécessite des connaissances très variées et très pointues. Certains diront qu'on trouve plein de tuto qui expliquent tout (c'est partiellement vrai), qu'ils ont bloqué l'authentification par mot de passe en ssh (c'est bien, mais vous avez aussi changés les ciphers par défaut j'espère ...), qu'ils ont "installé" iptables (iptables n'est pas un parefeu ... quid de l'ipv6 et des paramètres du noyau ?) et qu'ils utilisent la dernière version de php (l'ont ils configuré au moins ?). Et lorsqu'on essaye de bien faire les chose, on se retrouve souvent avec des problèmes lors des mises à jour (la fameuse mise à jour qui casse tout ou la règle de sécu qui bloque la mise à jour). Trop souvent on fait le choix de laisser des trous (ou d'en créer) pour que ça fonctionne. Dans le cas des NAS, on fait confiance à une entreprise et à ses dizaines voir centaines de développeurs, admin, ingé, ... pour tester et empaqueter les mises à jour de manière à ce qu'elles ne cassent pas tout. À un moment, il faut bien faire confiance sinon on n'avance pas. <un peu hs>Linux par exemple (vraiment linux, le noyau), les sources sont dispo donc on peut le compiler soit même, mais parmi les rares utilisateurs qui compilent eux même leur noyau (je ne parle pas de arch ou gentoo, la compilation est pré mâchée), combien sont aller lire et contrôler l'ensemble des lignes de code. Admettons que certains l'aient fait (en pratique ce n'est humainement pas possible, c'est devenu trop gros), qui a lu le source de son compilateur et l'a compiler soit même (et avec quoi ?) ? On peut aller loin comme ça, dans l'absolu il faudrait graver soit même le processeur et tous les chip de la carte mère ... à la main car sinon on devrait faire confiance à la machine de gravure, à son électronique et ses logiciels ...</hs> Au final, quelqu'un dont c'est le métier arrivera sans aucun doute à monter un système avec plein de fonctions et plus sécurisé qu'un nas grand publique mais pour la plupart des utilisateurs, c'est tout simplement mission impossible. Et pour les amateurs qui essaieront, il y a fort à parier qu'ils laisseront pleins de gros trous de sécurité par méconnaissance ou simplement par manque de temps (c'est comme ça qu'on se retrouve avec des millions d'appli "open" sur shodan). Quelques exemples pour illustrer mes dires : cherchez "apache authentification" dans votre moteur de recherche préféré Les quasi totalité des liens va vous proposer de créer un .htaccess dans le dossier de votre application en ajoutant la directive "AllowOverride all" : le .htaccess est quelque chose que même apache recommande de n'utiliser qu'en dernier recours et quand bien même, pourquoi autoriser TOUTES les exceptions de configuration alors qu'un "AllowOverride AuthConfig" serait suffisant ? cherchez maintenant : "installer apache php" vous allez trouver à chaque fois libapache2-mod-php (ou un truc du genre) le fait d'utiliser le module php compilé pour apache bride les performance de ce dernier ça diminue aussi la sécurité et la stabilité de votre serveur (apache et php on les mêmes droits et se partagent le même espace mémoire) et vous empêche de sécuriser vos applications (comme il n'y a qu'une seule instance php, toutes les applis se partagent les mêmes droits sur les fichiers, donc votre petite appli de test pourra aller lire les mots de passe de votre base de données dans la conf de votre CMS) et pour ceux qui ont déjà installé un serveur web, combien ont ne serait ce qu'entendu parler des entêtes Content-Security-Policy, XSS-Protection, Referrer-Policy ? FAUX pour les raisons que j'ai expliqué avant, sauf à être du métier et à n'avoir que ça à faire Il prend l'exemple des webmail mais comme son article est un peu vieux je passe ses critiques qui ne sont plus vraies pour la plupart, par contre il omet totalement d'indiquer qu'une webmail sans un serveur pour recevoir/envoyer (MTA) les mails et un autre pour gérer les boites ça ne sert à rien ! Et les groupware sont tout sauf sécurisés (même maintenant) et rarement compatible avec autre chose qu'eux même. Contrairement à ce qu'il indique, le problème n'est pas d'avoir un système centralisé de gestion des comptes et des droits, il en existe plein, mais d'arriver à ce que toutes les applications utilisent le même système ou (comble du luxe) fassent du SSO (SAML 2.0 par exemple). Sur ce dernier point, je vous souhaites bien du courage. Je partage en grande partie sa conclusion. -------- ps : je viens de voir que la plupart des points que j'ai évoqué l'ont déjà été dans les commentaires de l’article

Pour le certificat, il faut vérifier que tu as bien autorisé le port TCP 80 dans le firewall du nas et pas seulement pour certains pays, au moins le temps de créer le certificat (et tous les 3 mois pour le renouveler). Le port SSH ne doit être ouvert QUE depuis ton réseau local. Si tu as repris mon exemple de règles, il l'est puisque les 3 premières règles (10.0.0.0/8 - 172.16.0.0/12 - 192.168.0.0/16) autorisent tous le trafic local.

Non, mais on peut imaginer une manip similaire que je ne tenterais sans être certain à 100% de mes sauvegardes. Retirer les 4 disques Installer un DSM avec la même version sur un autre disque Remettre le disque "normal" et croiser les doigts pour que DSM retombe sur ses pieds Si ça fonctionne avec le disque normal, tu peux tenter de remettre les 3 autres disques à coté d'un disques simple (DSM est en raid 1 sur tous les disques) Perso je préfère encore réinstaller DSM surtout que si la base est sur la partition système, elle sera détruite dans les 2 cas. --- Je viens de regarder sur mon nas, les fichiers de database sont sur le volume (dans /volumeX/@database/mysql), pas sur la partition système, donc une réinstallation est envisageable je pense.

Non, mais si ta partition système est pleine, ce n'est pas surprenant.

Ça je ne sais pas.

https://www.synology.com/fr-fr/knowledgebase/DSM/tutorial/General/How_to_reset_your_Synology_NAS#t2 https://www.synology.com/fr-fr/knowledgebase/DSM/tutorial/General/How_to_reset_your_Synology_NAS#t3

Si tu n'arrives pas à te connecter même en ssh, tu peux tenter d'attendre demain 6h (c'est à cette heure que les logs tournent, donc le nas doit être allumé AVANT), avec un peu de change ça libérera juste assez de place pour te connecter en ssh. Sinon 3 méthodes : reset simple reset complet (la conf va sauter) faire le ménage à la main depuis un pc sous Linux