Toutes les discussions

Bonjour, Un point important : la désinstallation de Plex sous DSM 7 ne supprime pas le dossier partagé PlexMediaServer, donc la réinstallation repart avec la même base et la même config. Si le problème vient de là, ça explique que rien ne change. Pour voir ce qui fait tomber le serveur, regarde la fin du fichier Plex Media Server.log dans PlexMediaServer/AppData/Plex Media Server/Logs (accessible via File Station), juste après un arrêt. La dernière erreur avant la coupure donne souvent la piste. Comme ça se coupait déjà au bout de quelques heures avant la mise à jour, je pencherais pour une base de bibliothèque abîmée ou un manque de mémoire (le 416play n'a que 1 Go). Le Moniteur de ressources pendant que Plex démarre permet de vérifier la RAM. Pour tester la base, arrête Plex, renomme le dossier "Plex Media Server" (sans le supprimer, c'est ta sauvegarde) et relance : s'il tient avec une config neuve, c'est bien la base. Tu pourras ensuite remettre l'ancien dossier ou repartir sur une bibliothèque propre. Si même avec une config neuve il s'arrête tout de suite, essaie d'installer manuellement la version précédente (.spk sur le site de Plex) pour voir si c'est la 1.43.3 qui pose souci sur ce modèle.

Bonjour, considérant le dernier post de @rvabouc j'ai été ausculté le log acme.sh.log et effectivement j'y trouve le même genre d'entrées à la fin de la dernière session acme avec des *:* Mais je n'ai pas d'idée sur ce que ça peut être. En attendant le script fonctionne très bien depuis longtemps.

Moi c’est Fabien, 55 ans (Landes) dans l’informatique depuis 30 ans avec MdM Services. Côté NAS, je tourne sous TrueNAS 27 RC1 sur HPE gen10+ Dessus : Nextcloud, Jellyfin, quelques conteneurs, le tout derrière un reverse proxy avec Authelia. Avant ça, j’étais sur Synology. Ce qui m’a toujours manqué sur TrueNAS, c’est un bureau web à la DSM. J’ai fini par le développer : ça s’appelle Desktroo, un bureau dans le navigateur pour TrueNAS (à partir de la version 25), avec gestionnaire de fichiers, conteneurs, téléchargements, widgets, etc. Si ça intéresse du monde, j’en parlerai dans la section adaptée. Je suis là pour échanger sur l’auto-hébergement, apprendre des configs des autres et donner un coup de main quand je peux. À bientôt sur le forum !

Bonjour, Sur le principe, un expandeur SAS peut parler à un disque sur n'importe lequel de ses phys, port externe compris. La vraie question est la façon dont Adaptec configure ces deux ports dans le firmware de la 82885T : s'ils sont réservés à la liaison vers l'hôte ou vers un autre expandeur en cascade, les disques ne seront jamais vus, quel que soit le câble. Si c'est ce que dit le manuel, c'est lui qu'il faut croire plutôt que Gemini. Avant de conclure, deux tests simples pour isoler le problème : 1. Branchez un seul disque directement sur la nappe SFF-8644 vers SATA, avec le même adaptateur SFF-8482 que sur les ports internes, sans passer par la cage Rosewill. La cage est prévue pour du SATA, et c'est le maillon qui change le plus entre vos deux montages. 2. Avec la 9302-8i en firmware IT, sas3ircu 0 display liste l'expandeur et les disques attachés. Si rien n'apparaît derrière les ports externes même avec un disque branché en direct, c'est la configuration de la carte, pas les disques. S'il vous reste un port interne libre sur la 82885T, le contournement le plus simple est d'y brancher les disques et de sortir vers la cage avec une équerre passive SFF-8643 vers SFF-8644. Bon courage !

Bonjour à tous, Je vous présente Archive Station, une application gratuite et open source pour télécharger les fichiers d'un item Internet Archive directement sur un NAS Synology. Le principe : coller une ou plusieurs URL Archive.org, choisir les fichiers souhaités, puis lancer les téléchargements. Chaque URL possède son propre dossier, avec conservation de l'arborescence. L'application s'ouvre dans une fenêtre du bureau DSM, sans Docker et sans connexion supplémentaire. Elle propose notamment : - Progression par fichier, débit et estimation du temps restant. - Pause, reprise, annulation et reprise après redémarrage. - Vérification SHA-1/MD5 lorsque les empreintes sont disponibles. - Planification, limites de débit et téléchargements simultanés. - Historique du débit sur 24 heures et rapports texte. - Interface disponible en 27 langues. Compatibilité actuelle : DSM 7, processeur x86_64. Testé sur DS918+ avec DSM 7.1.1. L'accès à l'application nécessite une session administrateur DSM. Pas encore de paquet ARM. Installation : télécharger ArchiveStation-1.0.0-1-x86_64.spk, puis utiliser Centre de paquets → Installation manuelle. Télécharger la version 1.0 : https://github.com/jbdemonte/synology-archive-downloader/releases/tag/v1.0.0-1 Documentation et code source : https://github.com/jbdemonte/synology-archive-downloader Je recherche des retours sur d'autres modèles et versions de DSM. Si vous essayez, indiquez votre modèle, votre version DSM et les éventuels problèmes rencontrés. Vous pouvez répondre ici ou ouvrir une issue GitHub : https://github.com/jbdemonte/synology-archive-downloader/issues Le projet est indépendant de Synology et d'Internet Archive, et distribué sous licence MIT. Merci pour vos retours !

Salut la communauté, JB, basé dans le sud-ouest, développeur web depuis 2 décennies... et owner d'un syno DS918+

Bonjour à tous, A mon tour de remercier le/les auteurs de ce Tuto bien utile. Il fonctionne pour moi depuis des années, du moins pour ce qui est du renouvellement des certificats. Ceci dit, en parcourant ce tuto pour des soucis de Reverse Proxy, j'ai vu que spinoutbo189 évoque les mêmes symptômes que moi à savoir un arrêt inattendue du conteneur Acme quotidien. Je m'y étais habitué mais pour le coup je vais reprendre ce sujet car ça pollue le service de notifications. En regardant les logs (acme.sh.log), plusieurs choses m'interpellent : di='/acme.sh/account.conf' Not a directory, skipping: /acme.sh/account.conf di='/acme.sh/acme.sh.log' Not a directory, skipping: /acme.sh/acme.sh.log di='/acme.sh/http.header' Not a directory, skipping: /acme.sh/http.header Apparemment logique puisque ceux sont des fichiers et non des répertoires, mais ça n'explique pas pourquoi il y a ces msgs. Et le plus curieux se trouve à la fin des logs : di='/acme.sh/*:*' Not a directory, skipping: /acme.sh/*:* errorlevel='3' setlevel='2' Je n'avais jamais fait attention, mais l'on peut voir *:* qui devrait être à mon sens *.* Je ne sais pas si c'est ce qui explique mon problème mais j'avoue sécher sur ce point. Une idée ? Merci

Bonjour mic13710? merci de vos réponses et désolé de mes questions parfois bêtes ! Cordialement

Salut Merci pour ta réponse Pourquoi ? edit : j'ai fait ces modifications : Le pare-feu DSM est désormais activé, avec une règle autorisant uniquement mon réseau local, suivie d'une règle refusant les autres connexions. J'ai également désactivé QuickConnect et les six redirections NAT/PAT qui existaient sur ma Livebox (FTP, HTTP, DSM 5000/5001, WebDAV et un autre service). La DMZ est vide, aucune redirection UPnP ne concerne le NAS, et aucune ouverture de port ou de protocole IPv6 n'est configurée. Le pare-feu de la Livebox est sur « Moyen ».

Est-ce que certains ports du NAS sont exposés sur Internet ? Si oui, configurer le pare-feu du NAS pour n'autoriser que les connexions depuis le réseau local (autoriser 192.168.0.0/16 et bloquer tout le reste).

Mise à jour après une nouvelle récidive et analyse des logs par chat : Le problème s'est reproduit. Cette fois j'avais activé SSH afin d'essayer de récupérer des informations avant de redémarrer. Pendant le blocage : le NAS répondait toujours parfaitement au ping ; les ports SSH (22), DSM (5000) et SMB (445) acceptaient toujours les connexions TCP ; mais SSH restait bloqué avant même l'affichage de la bannière (kex_exchange_identification ... timeout) ; une requête HTTP sur le port 5000 établissait la connexion mais ne recevait aucun octet ; SMB ne répondait plus non plus ; même un arrêt normal demandé avec le bouton POWER est resté bloqué plus de 10 minutes, ce qui m'a finalement obligé à l'éteindre de force. Après redémarrage, SSH et DSM fonctionnent immédiatement et le RAID est toujours sain (4/4). Analyse des logs persistants du noyau Sur deux incidents différents, le noyau signale des kworker bloqués pendant plus de 120 secondes avec pratiquement la même pile : schedule_timeout wait_for_completion kthread_create_on_node create_worker manage_workers worker_threadPremier incident : apparition environ 36 minutes après le boot. Deuxième incident, après un autre redémarrage : apparition environ 2 h 06 après le boot. Dans le premier cas, le même worker reste bloqué et d'autres tâches finissent ensuite par se bloquer également (systemd-journal, autres kworker, puis plus tard dockerd et certaines opérations Btrfs). J'ai en parallèle recherché dans les logs : erreurs SATA / hard resetting link / failed command / I/O error : aucune trouvée ; erreurs ou dégradation RAID : aucune ; erreur/abort Btrfs : aucune ; OOM / manque de mémoire : aucune ; machine check / watchdog / soft-hard lockup : aucun ; erreurs réseau CRC/drop/timeout : compteurs à zéro. Les quatre disques continuent par ailleurs d'être reconnus normalement après reboot et le RAID reste 4/4. Un autre élément intéressant : pendant un des blocages, les logs DSM ont temporairement considéré les quatre disques comme "Abnormal", puis immédiatement "Normal", avec également des échecs temporaires de lecture de leurs numéros de série, alors que le RAID md restait bien à 4/4. Cela pourrait expliquer les voyants orange sans forcément indiquer une panne simultanée de plusieurs disques. À ce stade je n'ai trouvé aucune erreur SATA explicite permettant de l'étayer. Le point reproductible le plus net est actuellement ce blocage noyau/workqueue autour de : wait_for_completion -> kthread_create_on_node -> create_worker -> manage_workers Je ne sais pas si c'est la cause initiale ou la conséquence d'un autre problème noyau. Le SysRq fonctionne sur ce NAS. Au prochain blocage, si j'arrive encore à ouvrir une session SSH suffisamment tôt, je tenterai de récupérer immédiatement les tâches bloquées avec SysRq-w et dmesg avant tout redémarrage. Si quelqu'un connaît ce type de blocage kthread_create_on_node/create_worker sous DSM 7.2.2, ou a une idée de ce qui pourrait empêcher ainsi la progression/création des threads noyau, je suis preneur.

Bonjour Odin, Bonne nouvelle : le reset de 3 secondes ne touche pas aux données, il remet seulement le mot de passe admin et les réglages réseau par défaut (à condition de l'avoir fait NAS allumé, en maintenant le bouton jusqu'au bip). Ensuite, dans Qfinder Pro, double-cliquez sur le NAS pour ouvrir la page de connexion et essayez l'identifiant admin avec le mot de passe admin. Si c'est refusé, sur les firmwares plus récents le mot de passe par défaut est l'adresse MAC du port LAN 1, en majuscules et sans les deux-points (elle s'affiche dans Qfinder Pro et sur l'étiquette du NAS). Pour le 2e disque : éteignez le NAS, remettez-le dans la même baie, puis rallumez avant de vous connecter. Et si Qfinder ou la page web propose une "initialisation" ou une installation, ne validez surtout pas, ça effacerait les disques. Dans ce cas, revenez ici avant. Pas besoin d'un ticket QNAP pour tout ça.

Bonjour à tous, Après des moments difficiles, j’essaye de remettre mon Nas en service. Et vu mon âge ce n’est pas une mince affaire pour moi. . Q Finder Pro est installé et détecte le NAS Ø Le SN Q1531l 16686 n’est pas accepté pour ouvrir un ticket sur le site QNAP Ø De plus je ne me souviens plus de mon mot de passe, ni de mon identifiant. Ø J’ai aussi fait un reset de trois secondes et enlevé le 2° disque de peur de perdre mes données; Voila ou j’en suis si une personne peut me venir en aide je serais bien contant. D’avance merci Cordialement ODIN

Bonjour, Comme les 4 voyants restent verts et que tu reçois des mails d'événements, le NAS a l'air de tourner : c'est plutôt l'accès réseau ou DSM qui décroche. Ça vaut le coup de copier ici le texte exact d'un des mails reçus la nuit. Côté réseau, regarde dans l'interface Freebox quelle IP a le NAS et mets-lui un bail DHCP statique. Si le NAS est en IP fixe dans la plage DHCP de la box, un autre appareil peut récupérer la même adresse, et ça donne exactement ce genre de disparitions intermittentes. Côté DSM, la page de connexion qui met une demi-heure et le champ mot de passe qui ne s'affiche jamais font penser à un NAS saturé. Dès qu'il répond, ouvre le Moniteur de ressources pour voir si le CPU ou les disques sont bloqués à 100 %, et vérifie l'état des disques dans le Gestionnaire de stockage.

Bonjour, 1) merci pour ta réponse, et en particulier pour aoir attiré mon attention sur la question des versions de DSM. Si je me souviens bien, Synology Assistant propose par défaut la màj de DSM, mais permet aussi d'utiliser un fichier .PAT préalablement sauvegardé sur l'ordi. Quand même une remarque/question sur ce point: tu parles du .PAT 5.2-U9, mais il faut d'abord passer par le .PAT "de base" (DSM_DS415+_5967.pat), qui fait 190Mo, alors que le 5967U9-synology_avoton_415+.pat n'en fait que 27; question, car les releases notes pour DSM5.2 sur 415+ ne sont plus dispo sur le site de Synology: puis-je mettre directement la 5967-U9 (après la version de base), ou bien dois-je passer successivement la U1, la U2, etc? 2) je n'utilise pas l'agrégation de lien. Comme j'avais utilisé le fichier de config .DSS du 411+II pour le 415+, je ne pense pas que quelque chose ait changé dans la configuration réseau, mais à tout hasard, que dois-je vérifier dans le panneau de configuration "Réseau" du 415+ pour m'assurer que le problème ne vient pas de là? [Edit] j'ai retrouvé les release notes, mais rien n'est dit à propos de l'application des màj Updates (1 à 9 successives ou directement la U9). [Fin Edit]

Bonjour, Sur le principe oui : le DSM et la config sont sur les disques, donc en remettant les disques d'origine (même ordre de baies, NAS éteint proprement avant chaque échange) tu retrouves ton 415+ tel quel. Le seul vrai piège, c'est la version. Si l'install "propre" passe par Synology Assistant, il va proposer le dernier DSM dispo pour le 415+ (7.x), et quand tu remettras tes disques en 5.2-U9, le NAS risque de les voir comme "migrables" et de proposer une mise à jour. À ce moment-là, ne rien valider. Le plus simple pour éviter ça : faire l'install de test en installation manuelle avec le .pat 5.2-U9 récupéré sur l'archive Synology, comme ça les deux jeux de disques restent sur la même version. Au passage, si les deux ports LAN du 415+ sont branchés, vérifie l'agrégation de liens côté NAS et côté switch : un bond mal assorti peut justement faire tousser tout le réseau, internet compris.

Bonjour, depuis la migration des disques du 411+II dans le 415+ je constate des dysfonctionnements plus ou moins aléatoire et plus ou moins importants sur mon réseau. L'accès au 415+ est assez souvent plus ou moins ralenti, voire parfois complètement bloqué pendant quelques/plusieurs secondes, en écriture comme en lecture (c'est moins marqué en lecture); et ça s'accompagne en général de perturbations sur l'accès au 425+ et sur l'accès internet. À noter que l'inverse n'est pas vrai, à savoir que jamais un accès internet plus ou moins rapide, voire arrêté, ne perturbe mon réseau. J'ai longtemps envisagé un problème avec la carte réseau de l'ordi concerné, mais finalement je ne le pense pas car: - j'ai essayé de désactiver la puce réseau interne de l'ordi et d'utiliser un boîtier externe branché en USB3 sur l'ordi, mais ça ne résoud rien; - je n'ai pas fait d'essais aussi systématiques, mais à partir d'un autre ordi du réseau je n'ai pas de problème, aussi bien pour accéder au 415+ qu'au 425+ - si je n'ai pas accédé au 415+ depuis "un certain temps", l'accès au 425+ est normal depuis tous les ordis. Je ne vois pas en quoi un problème réseau (a priori logiciel?) sur le 415+ pourrait perturber aléatoirement le reste du réseau, mais je voudrais faire le test suivant: retirer les disques actuellement dans le 415+ et y mettre 4 autres disques pour faire une installation "propre" à partir de zéro, et voir si le problème existe toujours. Mais comme le 425+ n'est pas l'exact miroir du 415+, si le problème persiste je voudrais pouvoir remettre en place les disques initiaux dans le 415+, au moins pour le temps de trouver une solution plus pérenne (ou d'apprendre à plus ou moins contourner le problème...) => cette manip est-elle sans danger?

@GrosMatou vu ce qu'a trouvé Gfr44240, ça vaut le coup de vérifier si ton DS114 est joignable depuis l'extérieur aussi (redirection 5000/5001 sur la box, ou QuickConnect). Quand il répond de nouveau, jette un oeil au Centre des journaux, type Connexion : si tu vois des tentatives en rafale depuis des IP externes, c'est la même cause. Dans ce cas, active le blocage auto (Panneau de configuration > Sécurité > Protection), coupe la redirection et passe par un VPN pour l'accès distant. Un petit 114 sature vite sous ce genre de rafale.

Bonjour @SlipJMax , Soit attentif, car tu avais fait 2 fils de présentation. J'en ai supprimé un.

Bonjour à tous ! Déjà présent sur ce forum il y a plusieurs années suite à des problèmes avec mon premier NAS (209j) je reviens sous un autre compte car je n'ai plus mes identifiants et ai changé de mail, afin de me perfectionner et pouvoir faire partager mon expérience.

Bonjour, En fait après avoir réussi à me connecter par hasard j'ai remarqué que le NAS avait des demandes de connexions en permanence (20 par minutes) : ce qui bloquait tout accès. En coupant l'accès depuis l'extérieur c'est redevenu normal. A fait toujours avant de couper l'alimentation car cela peut dégrader le groupe de stockage et empirer.

@Lelolo Bonne question. Le fork n'a rien à voir avec le prix : Immich est gratuit et Immuch360 l'est aussi (même licence libre, code public sur GitHub). Il vient de ce que l'application mobile Immich ne fait pas, et ne prévoit pas de faire. Immich est une bibliothèque de photos avec serveur, et son équipe garde l'application mobile centrée sur ce serveur. La demande d'un afficheur 360° est ouverte sur leur dépôt depuis janvier 2024 et les propositions de code dans ce sens attendent toujours ; c'est leur choix de périmètre, que je respecte. Immuch360 part de leur application et ajoute ce qui n'y entre pas : - l'affichage en sphère des photos et vidéos 360°, de la 3D et du VR180, avec ou sans balises dans le fichier - la lecture directe d'un partage SMB ou WebDAV du NAS, sans serveur Immich et sans copie préalable - l'ouverture des fichiers bruts des caméras 360° (Insta360, GoPro, DJI) assemblés par l'application - une vue immersive sur Meta Quest Pour un utilisateur de Synology Photos, l'intérêt pratique est celui de ce sujet : les photos de drone qui n'ont pas les métadonnées exigées par Synology s'ouvrent quand même en 360° depuis le partage du NAS, sans retoucher les fichiers. Elle reste compatible avec un serveur Immich pour ceux qui en ont un, mais il n'est pas nécessaire. ++

ok je fait ça et je reviens vers vous Merci guillaume

Le problème est maintenant résolu. N'hésitez pas à ouvrir un nouveau message en cas de problème. Ceci est une réponse automatique.

Bonjour, Le schema ping OK + TCP 5000/5001 qui acceptent la connexion sans renvoyer d'octet, avec DSM et SMB morts, evoque un gel partiel: le noyau repond encore un peu, les services DSM non. Plusieurs LED disques orange alors que SMART/RAID etaient sains juste avant colle mieux avec alim, backplane ou controleur SATA qu'avec trois ou quatre disques qui tombent d'un coup. Des que DSM est de nouveau accessible, activez SSH (Panneau de configuration > Terminal et SNMP). Au prochain blocage, avant l'arret force, tentez une connexion SSH et relevez `dmesg | tail -100` (erreurs SATA, reset, I/O). Des resets SATA a repetition font du chassis le suspect n°1. La sauvegarde que vous avez deja faite est le bon reflexe en attendant.