Classement

Il n'y a plus de mise à jour automatique des versions mineures de DSM pour les modèles des séries ´16 à ´19 depuis DSM 7.2. Elles ne peuvent donc être faites que manuellement.

Installation du firmware Qnap QTS sur NAS Fujitsu Celvin via SSH Rappel: La majorité des serveurs NAS Fujitsu Celvin sont fabriqués par QNAP (Produits OEM ou Co-branding) ce qui signifie que les modèles Fujitsu sont des versions reconditionnées de modèles QNAP, avec un design légèrement modifié (logo, couleur) et un firmware spécifique. Le firmware de Fujitsu (Celvin OS) est très proche de celui de QNAP (QTS). Fujitsu assure la totalité des services comme pour tous produits Fujitsu: Support client, mise à disposition de mises à jours et d'applications qui lui sont propres, même si elles sont identiques à celles du Qnap. Parfois Fujitsu ne fait que changer le nom de l'application. Fujitsu dispose de ses propres serveurs pour les mises à jours et pour "app center". Pourquoi migrer de Fujitsu à QNAP? Fujitsu a cessé le suppot des NAS CELVIN. Par exemple les NAS sortis entre 2009 et 2012 ne sont plus pris en charge par Fujitsu depuis 2018. En 2025, Fujitsu a arrêté le serveur d'app center, Plus aucune application n’apparaît dans le magasin d'applications. La seule manière d'installer des applications est l'installation manuelle. En 2020 Fujitsu et Qnap ont décidé que Qnap poursuive le support pour les NAS concernés. Uns fois le NAS migré, il est pris en charge par QNAP et bénéfice de tous les services et supports de QNAP. La migration permet de bénéficier des mises à jours de sécurité du firmware QNAP. Elle permet de retrouver un app center fonctionnel et permet d'installer les anciennes applications qui y sont proposées. Même chez QNAP, certaines applications ne bénéficient plus de mise à jours, ce qui limite de l'utilisation des applications officielles. Mais beaucoup d'applications non officielles sont disponibles en paquets (qpkg), notamment sur le site myqnap.org. L'intérêt de la migration est essentiellement d'obtenir les mises à jours de sécurité de QTS. Pour bénéficier d'applications récentes, l’utilisation d'applications tiers est la meilleurs solution. Comment migrer? En accord avec QNAP, Fujitsu propose pour certains modèles une méthode automatisée par l'installation d'un paquet officiel (qpkg) qui permet d'installer le firmware QNAP (QTS) à la place de celui de Fujitsu par l'interface de gestion du NAS comme si on faisait une simple mise à jour. Le paquet modifie tout simplement le nom du modèle du NAS pour que la mise à jour vers le firwmware équivalent de chez QNAP fonctionne Les modèles concernés sont les suivants:Q805, Q905, QR806, QR1006, QE705, QE805, QE707, QE807. L'autre moyen de migrer est d'utiliser la méthode manuelle par SSH. Pour les modèles qui ne bénéficient pas de la méthode automatique, SSH est la seule méthode possible. Migration manuelle par SSH: Prérequis: Avoir un NAS fonctionnel: Avec au moins un disque dur configuré dans le NAS, qu'il soit accessible depuis votre PC avec l'interface de gestion Web et avec accès aux dossiers partagés depuis votre PC. A savoir: Les systèmes d'exploitation des NAS QNAP (et Fujitsu), sont basés sur un noyaux linux. Vous y retrouverez donc des programmes et structures similaires. Il est même possible d'installer une distribution Linux comme Débian sur le NAS. La méthode SSH utilise une procédure d'installation manuelle du firmware fournie par QNAP. Elle est réservée aux utilisateurs avertis, car elle permet d'installer un firmware dont le nom de modèle ne correspond pas à celui installé sur le NAS. Il faut être sûr d'avoir le firmware du modèle QNAP correspondant à votre NAS Fujitsu. Si vous installez le mauvais firmware, vous pouvez rendre votre NAS inutilisable! Vérifiez bien sur le site de QNAP si les caractéristiques sont les même que votre modèle Fujitsu. Après installation, le nom de modèle de votre NAS sera celui de QNAP, il sera reconnu comme tel par QNAP et app center proposera les applications compatibles avec votre modèle. Vous trouverez des ressources (Aides - How to) en français sur le site de QNAP https://www.qnap.com/fr-fr/how-to/search Il existe un wiki plus complet en angalis https://wiki.qnap.com/wiki/Main_Page Procédure: Télécharger le firmware QNAP correspondant à votre modèle Le firwmare se présente comme une image de disque (.img) qui est compressée au format zip (.zip): Allez dans le Centre de téléchargement QNAP: https://www.qnap.com/fr-fr/download Sous "Type de produit", sélectionnez "NAS / Extension". Sous "Baie", sélectionnez le nombre de baies de lecteur pour votre NAS. Sous "Modèle", sélectionnez QNAP correspondant à votre NAS fujitsu. Dans la section "Télécharger les éléments", cliquez sur Système d’exploitation. La liste qui apparait est celle du firmware (Système d'exploitation) avec le plus récent en haut. Téléchargez le fichier en cliquant dans la colonne "Lien de téléchargement". Décompressez le fichier zip. Copiez le firmware dans le dossier Public du NAS: Vous pouvez renommer le ficher "image" (.impg). J'ai effectué la migration d'un Q703. Je prends donc ce modèle comme exemple. J'ai nommé le ficher image en "TS-221.img". Remplacer "TS-221.img" par le nom que vous avez choisi dans le reste du tutoriel. Par l'explorateur de fichiers de votre système, copiez le fichier image dans le dossier Public du NAS. Autoriser la connexion SSH dans le NAS: SSH, pour Secure Shell, est un protocole de communication réseau qui permet d’établir une session chiffrée entre deux machines, typiquement un client et un serveur. Si la connexion au NAS par SSH n'est pas activée, vous devez l'activer soit par l'interface du NAS, soit avec Qfinder. Si besoin aller voir l'aide QNAP: https://www.qnap.com/fr-fr/how-to/faq/article/comment-acc%C3%A9der-%C3%A0-mon-nas-qnap-en-utilisant-ssh Accédez à votre NAS avec SSH: Vous devez ouvrir une console (un terminal) prenant en charge SSH. Sous MacOS et Linux, cette fonctionnalité est généralement activée par défaut. Sous Windows, elle n'est pas toujours disponible. Sous Windows 10 ou 11, Vous devez activer le "client OpenSSH" dans les paramètres de Windows. Si vous ne savez pas comment faire, vous trouverez des tutos sur internet. Sinon, vous pouvez installer un programme comme "Git Bash" ou "PuTTY". La page d'aide indiqué ci-dessus montre la méthode pour MAC et pour Windows avec "PuTTY". Installer le firmware avec l'image: Dans la console que vous avez ouverte, saisissez les commandes suivantes et terminez par la touche "Enrtée" pour validez (exécutez) les commandes. Vous pouvez les copier-coller. N'oubliez pas d'adapter les valeurs à votre configuration (adresse IP du NAS, nom de l'image). Code: ssh Code: ssh admin@ipRemplacez « ip » par l'adresse IP de votre NAS. Le système vous demande ensuite le mot de passe. C'est celui par défaut c'est « admin ». [Par cette commande, vous vous connectez au NAS à distance en vous identifiant comme l'utilisateur "admin", comme vous le faites lorsque vous accédez à l'interface de gestion du NAS avec votre navigateur, mais ici vous le faite en ligne de commande par le protocole SSH.] Saisissez ensuite : Code: mkdir /mnt/HDA_ROOT/update[Cette commande créé le répertoire "update" dans le répertoire HDA_ROOT.] Code: rm -rf /mnt/update[Cette commande efface le contenu du répertoire "update" au cas où il il ne soit pas vide.] Code: rm -f /tmp/update_process[Cette commande efface un éventuel fichier temporaire qui serait resté d'une précédente mise à jour] Code: ln -sf /mnt/HDA_ROOT/update /mnt/update[Cette commande créé un lien symbolique entre les deux emplacement.] Code: /etc/init.d/update.sh /share/Public/TS-221.img[Cette commande lance le "script" ou programme d'installation du firmware (update.sh) et lui indique ne nom et l'emplacement de l'image à installer "TS-221.img" dans le dossier Public du NAS.] Le processus d'installation se déroule et des informations apparaissent dans le terminal tout au long du processus. Le processus peut prendre un certain temps. Vous verrez apparaitre le nom du modèle d'origine du NAS, Q703 dans mon cas : "model name = Q703" Et une autre ligne plus bas vous indiquera le nouveau nom de modèle, TS-221 dans mon cas. Si tout se déroule correctement, la procédure se termine par le message : « Mise à jour terminée ». Saisissez ensuite : Code: rebootAprès le redémarrage, qui est assez long, vous trouverez la nouvelle interface sous QTS en vous connectant au NAS avec votre navigateur ! Dans mon cas, tout était intact : mes applications et mes données étaient toujours présentes. [Pour information, après la migration j'ai voulu faire une réinitialisation sans formatage des disques, Mais lors du redémarrage, le système m'a forcé à réinstaller le firmware. Il suffit de sélectionner le fichier image (TS-221.img dans mon cas) et de laisser le processus se faire.] Il est alors possible de créer un compte sur le site de QNAP, d'enregistrer le NAS et d'utiliser tous les services QNAP. N'hésitez pas à partager vos expériences de migration de votre NAS ou à les publier sur le forum! Je suppose que cette méthode fonctionne avec tous les modèles QNAP, car la documentation QNAP ne mentionne aucun modèle particulier. Page de l'aide du site QNAP pour la mise à jour par SSH: Comment mettre à jour manuellement le firmware par SSH ? Page du site Wiki QNAP pour la mise à jour par SSH: : Manually Updating Firmware Au cas où votre NAS ne démarre plus: Récupérer un NAS ARM ancienne génération Récupérer un NAS X86 ancienne génération

@Lelolo Oui, j'aurais d'ailleurs mieux fait de rédiger en français d'abords et traduire en anglais pour poster sur "community Qnap". Mais au départ, je pensais seulement modifier le tuto anglais que j'avais trouvé pour le TS-219, mais finalement j'ai tout repris... Je ferais une publication (post🇬🇧) en français. Bonne soirée

Bonjour @C. Trx , Pour le choix des disques oui , il faut prendre des disques CMR, pas obligatoirement spécial nas. Dans ton cas je te conseille de prendre le même type de disque que celui que tu as dans le nas, si tu veux pas des soucis (du moins dans la même marque et la même vitesse de rotation). Apres un onduleur c'est indispensable quand on fait un raid avec un nas

Salut, J’ai fait un test avec AllDebrid : il y a un fichier host. Tu renseignes ton compte avec une clé API qu’il faut générer sur le site, et ensuite, quand tu veux faire un téléchargement, tu mets n’importe quel lien dans Download Station et ça télécharge comme par magie. C’est vraiment trop bien, et en plus avec des sacrées vitesses : j’arrive presque à 300 Mo/s

çà j'ai bien compris mais si je mets un fichier sur D1 il seras copier a l’identique sur D2, donc si D1 ou D2 Crame j'ai juste a changer le disque HS et le clonage se referras Il il sert pour crée des copie distante de fichier déja présents sur 2 PC en cloud personnes, en gros - PC : Fichier sources - NAS : Copies sync des fichiers sources - Disques Externe 4To ( sauvegarde mensuel synchronisé ) le trio 3 2 1 habituel

Oui. La mise en miroir nécessite beaucoup de travail sur les disques, particulièrement sur un modèle d'entrée de gamme. Il faut se montrer patient.

Bonjour, il semble que je n'aurai pas besoin de poser ici d'autres questions, car le support Synology est très réactif (et efficace), malgré le grand âge des appareils concernés: c'est d'abord une IA qui m'a répondu, et en réponse à une de mes questions, m'a proposé une procédure de test j'ai répondu que d'après la procédure le Syno semblait bien mort, et j'en ai profité pour poser les questions que j'évoquais dans mon post précédent (à ce moment je n'étais pas sûr que la réponse ait été générée par une IA) cette fois c'est un humain qui m'a répondu, et s'il a confirmé ne rien pouvoir faire pour réparer le 411+II, il m'a bien renseigné sur la migration des disques du 411+II dans le 415+; il m'a aussi rassuré sur la possibilité de continuer à utiliser mes disques Seagate IronWolf en les installant dans un Synology de la gamme actuelle. Bon, maintenant il va s'écouler un certain temps avant que j'entreprenne la migration, car avant de modifier quoi que ce soit sur le 415+, je veux recopier ses fichiers sur des disques externes, et avec environ 35To à sauvegarder, ça va être long, que ça soit avec Robocopy ou avec FileStation.

Bonjour, Quelqu'un aurait-il un lien pour télécharger un fichier host (download station) pour le site Updloady.io s'il vous plait ? Ou un tuto sur comment en créer un ? J'ai vu sur Google qu'il y avait un topic à ce sujet sur le forum mais je n'y ai pas accès : https://www.google.com/url?sa=t&source=web&rct=j&opi=89978449&url=https://www.nas-forum.com/forum/topic/81968-fichier-host-pour-uploadyio/%3Fdo%3DfindComment%26comment%3D1319513384&ved=2ahUKEwiKuK_mrpWLAxXZ3AIHHQ3lJ0gQFnoECAcQAQ&usg=AOvVaw1KQ-cOebOdNKcHwwUFaVT8 Merci d'avance

<Slt @KeizerSauze , je vais te répondre que sur la partie que je pense maîtriser... donc hors univers Apple et Mullvad VPN. Lorsque tu es sur ton UI web de TailScale [TS], l'ensemble de tes machines doivent être sur le même Tailnet et donc être toutes "connected" et administrable dans le même parc machines. Tu ne dois pas toucher à l'exit Node qui ne doit te servir qu'au cas ou tu voudrais que cela soit le device sur lequel tu l'actives qui devient la porte d'entrée pour internet. Normal que tu ne puisses pas l'activer/désactiver sur le NAS puisque sans son internet tu ne peux plus le voir. ^^ Donc chaque device mobile peuvent activer l'exit Node mais pas les autres. Pour ce qui est de la visualisation de ton fichier... fait un essai hors TS, repère bien les répertoires depart/arrivée et refait la même chose sous TS tu dois obtenir le même résultat. Pour aller plus loin dans la vérification : - Pour vérifier réellement l’usage DNS sur le NAS, il faut faire un test direct (ex. cat /etc/resolv.conf puis nslookup vers un domaine) pour voir vers quel serveur DNS il résout réellement. - Installer un client NextDNS par appareil (ou configurer explicitement le resolver sur DSM) donne une meilleure traçabilité que de s’appuyer uniquement sur Tailscale DNS global. Ce qui compte, c'est le chemin pour y arriver... pas l'arrivée... quoique ;-)

Les termes utilisés adresses des points différents. La tendance marketing actuelle est d'utiliser le (nouveau) terme Immuable comme équivalent au terme (historique) WORM. Mais il s'agit de deux capacités différentes. En dehors de faire plus moderne te plus compréhensif que Write Once et Read Many, je crois que cela vient de la traduction du terme anglais qui, une fois traduit en français, laisse penser à un comportement supposé... L'immuabilité assure que les datas ne peuvent être altérées par un malveillant externe. Mais dans les faits cela n'interdit pas (nécessairement) une modification ou suppression si l'opération s’exécute avec les bons droits. Dans le langage courant, le WORM est une forme d'immuabilité (en français), mais sans possibilité réelle de modification ou de suppression, même avec les bons droits et même avec une backdoor éventuelle du fournisseur (matériel ou logiciel). Le WORM est une écriture dans le marbre :) donc définitive. Historiquement, cela permet d'accéder à un niveau d'enregistrement dit réglementaire ou légal (par abus de langage). La donnée enregistrée en mode WORM (avec la méta-data qui va bien) peut faire office de preuve juridique = la nature de la donnée à sécuriser peut donc influer le choix. Dans le cas d'une sauvegarde pour se prémunir d'un malware, l'immutabilité peut suffire, mais attention un Snapshot n'est pas une sauvegarde. Mais simplement une prise de pointeurs à un instant sur une source. Cela ne garantit pas une complète sécurité contre la malveillance (principalement en cas de vol d'identité). Alors que le WORM garantie, que même en cas de vol d'identité (donc avec des droits de Super Super User) il ne doit pas être possible d'altérer la donnée. Donc dans ce cas, mettre sous WORM une donnée avec une rétention de 1 an doit signifier qu'il sera impossible (sauf casser la machine🔥) de supprimer ou modifier la data ou tout autre infos associées comme la date de rétention - une malveillance avec les bons droits peut juste être une modification de la durée de conservation (...) pour une suppression automatisée ☹️ S3 n'est pas du WORM ou de l'immuabilité, c'est juste un formalisme de communication pour envoyer des data (put) et en récupérer (get) via le protocole HTTP/HTTPs. Il est le plus pratique (et aussi le plus utilisé comme standard de faite) pour des envoies vers un service Cloud. Mais une réplication pourrait aussi bien faire l'affaire (un bon rsync 🤔). Une fois ce blabla partagé, le choix du mode de la sauvegarde dépend du coût (besoin pro ou perso), de la perf attendue (bien valider le temps sur la restitution souhaitée en cas de perte de la source, mais 500GB ce n'est pas énorme) et de l'objectif de sécurisation à atteindre (vrai WORM ou juste une copie sécurisée). Bref, un bon stockage S3 dans le Cloud (ou équivalent) peut faire l'affaire : à voir les conditions du fournisseur en garantie de conservation réelle (certains proposent de la multi copies = le site du fournisseur peut aussi flamber...), en coût de conservation et en restitution (glacier implique un délai non immédiat). Il y a même des fournisseurs avec une offre de vérification du contenu de la donnée (détection d'une malveillance lors des dépôts). Il serait dommage d'archiver un malveillant 😮et de le réintroduire en pensant faire une restitution propre. Pour ordonnancer le transfert tous les mois, ce n'est qu'une opération de sauvegarde (certains vont dire d'archivage) vers une destination externe (préférable) ou interne à l'entreprise. Cette destination sera alors WORM (plu sécure) ou immuable (plus pratique pour des changements souhaités) dans notre cas. Pour finir, je viens de lire cet article au sujet Restic. Je ne l'ai pas utilisé donc pas d'expérience à partager, mais il me semble être un bon soft pour envoyer vos données vers un Cloud S3 de votre choix : https://blog.stephane-robert.info/docs/cloud/outils/restic/

Bon finalement j'ai pu tout récupérer depuis linux et j'ai retrouvé le fichier .pat...sur le NAS...quel boulet (j'étais jeune et bête)...C'est la version modifié du 1635 pour tourner sur un CS406, si qq1 est intéréssé un jour (avant que je le reperde)...il fait 153Mo

Le Reverse Proxy n'est pas un moyen de sécurisation. C'est un mode de connexion qui permet de s'affranchir des ouvertures de ports en utilisant qu'un seul port. C'est généralement le 443 qui est le port https par défaut, mais vous pouvez très bien prendre un autre port si vous voulez, avec la contrainte de devoir le renseigner dans l'url. Il est illusoire de croire que le changement de port constitue une protection efficace. Ca ne fait que retarder (un peu) les attaques. Il n'y a pas de connexion externe sans risque et le seul moyen efficace pour les éviter c'est de ne pas les autoriser, ce qui limite drastiquement l'usage d'un NAS. Sinon, c'est au parefeu qu'il revient le rôle de protection. C'est lui qu'il faut régler pour limiter l'exposition vers l'extérieur. Le reverse proxy permet toutefois un réglage plus fin grâce aux profils de connexion. On peut en définir plusieurs pour protéger chaque application de manière spécifique. Perso, je n'en utilise qu'un pour protéger les applications sensibles pour lesquelles je ne veux qu'une connexion locale ou via le VPN. L'accès à DSM par exemple n'est possible de l'extérieur que via le VPN et à quelques ip publiques fixes de confiance qui m'appartiennent et qui ne sont là juste en cas de dysfonctionnement du VPN. Je n'ai pas de problème d'identification avec mes applications nomades. Chacune d'elle se connecte avec un ndd spécifique pour chaque application et certaines avec des identifiants différents. Mais peut-être est-ce du au fait que les identifiants sont enregistrés dans mon smartphone. L'accès à toutes les applications sensibles sont protégées soit par biométrie, soit par code. Les autres utilisent un identifiant dont les droits sont réduits au strict minimum.

Comme je bosse sur un projet utilisant Tailscale, ton sujet m'a interpellé en ai discuté avec la LLM qui me donne la main et voilà ce qu'il en ai ressorti en espérant que cela puisse t'éclairer : Pourquoi NextDNS “voit” 4 IP mais seulement 3 Apple🔍 Ce qui se passe réellementApple Private Relay : intercepte une partie des requêtes DNS + HTTP(S) les fait sortir via des egress Apple (Cloudflare / Akamai / Apple) masque l’IP source réelle parfois split le trafic : une partie passe par le DNS “système” une autre ne passe PAS par ton NextDNS 👉 Résultat : NextDNS voit : des IP Apple relay parfois plusieurs IP pour un seul device Le message NextDNS est volontairement flou car Apple ne documente pas précisément le mapping 🧠 Conclusion ➡️ Les 4 IP ≠ 4 machines ➡️ Ce sont des sorties Apple Relay, pas des hôtes réels Pourquoi les NAS Synology n’apparaissent PASEt là on arrive au point clé 👇 ⚠️ Les NAS n’utilisent probablement PAS NextDNSCas les plus fréquents sur DSM : ❌ Le NAS utilise : le DNS du LAN ou /etc/resolv.conf généré par DSM ou un fallback IPv6 ❌ Le trafic DNS du NAS : passe en dehors de Tailscale ou passe par Tailscale mais ne fait aucune requête DNS observable (cache, peu d’activité) ❌ Tailscale DNS ≠ garantie d’usage réel 🧠 Point fondamental ➡️ Tailscale DNS est déclaratif, pas coercitif Réponse à la question centrale 👉 Réponse honnête : NON, il n’en a aucune certitudeEt actuellement : ❌ Apple = couverture partielle (Private Relay) ❌ NAS = probablement hors périmètre ❌ Tailscale = aucune visibilité par device 🧭 Recommandations claires (par ordre de maturité)🟢 OPTION 1 — Vérification factuelle (indispensable)Sur chaque NAS Synology : cat /etc/resolv.conf Puis : nslookup google.com ➡️ Vérifier vers quel DNS ça sort réellement 🟢 OPTION 2 — Désactiver Apple Private Relay (si objectif = contrôle DNS)Sur Apple : iCloud → Private Relay → OFF 💬 Sans ça : aucun DNS central ne peut être fiable NextDNS, Pi-hole, AdGuard = tous aveugles partiellement 🟡 OPTION 3 — Forcer NextDNS par appareil (recommandé)Au lieu de “DNS global Tailscale” : Installer NextDNS client : sur macOS sur iOS sur DSM (possible via script / container sidecar) ➡️ Là, NextDNS tagge chaque appareil ➡️ Plus de doute ➡️ Plus de mapping fantôme 🟡 OPTION 4 — Architecture propre (niveau Rahan 🧠) Tailscale : transport DNS : local-first Apple Private Relay : OFF sur machines de confiance 👉 Sinon : Il empile des couches qui s’aveuglent mutuellement 🧩 Synthèse ultra-courte à transmettre à ton ami

Bonjour, c'est corrigé. merci

Aucun souci sur le mien, ni sur mes App docker

Çà pourrait aussi être mon diagnostic, à voir ce que veut dire une alimentation "compatible", même si elle date de 2024

C'est toujours difficile d'apporter des réponses à ce genre de problème. Ca peut être l'alimentation (alimente un disque mais pas les 4), un disque HS qui bloque le boot, le système corrompu. Si le NAS ne démarre pas avec les 4 disques, j'aurais tendance à dire que c'est l'alimentation qui est défaillante.

merci pour la réponse. C'est fait et nous avons eu la réponse. Effectivement il s'agit d'un bug sur la 7.3 (depuis la 1ere version). Un correctif est prévu (quand ?). En attendant pour résoudre le problème nous avons découvert qu'il ne fallait pas utiliser la planification de synchronisation de l'AD sur le NAS. C'est ce que nous a confirmé Syno. Dommage que ce genre de bug majeur ne soit listé quelque part, avec le contournement possible. Cela éviterait 2 jours de travail avant de comprendre et de trouver nous-mêmes la solution.

Il faut espérer que les constructeurs de disques dur mettent de la mauvaise volonté pendant quelles mois/ Années. cela serait bienvenu de leur part. Un peu comme le passage des disques CMR et SMR dans une même gamme de disques.