PiwiLAbruti

Télécharge le dernier firmware disponible pour le DS107+ (3.1-1639) : https://usdl.synology.com/download/DSM/release/3.1/1639/ Ouvre le fichier .pat avec 7zip. Tu y trouveras une image du disque dans laquelle il y a tout le contenu de DSM, dont le fichier que tu cherches.

Ce sujet n'a été rédigé qu'à titre informatif. Par défaut, le relai SMTP de Mail Server n'accepte que les clients appartenant aux réseaux auxquels ses interfaces réseau sont directement connectées. Pour être plus clair, si le réseau local auquel le NAS est connecté est 192.168.1/24, le relai SMTP de Mail Server n'acceptera que les clients appartenant à ce réseau (192.168.1.x). Si votre réseau local est composé de plusieurs réseaux privés (192.168.1/24, 10.99.1/24, 172.29.1/24, ...) routés entre eux et que le NAS n'est connecté qu'à un seul de ces réseaux, Mail Serveur refusera les clients connectés aux autre réseaux. La procédure de modification décrite ci-dessous est obsolète car Synology a rajouté l'instruction mynetworks directement dans le fichier de configuration main.cf afin de corriger le problème. Le support Synology m'a indiqué la procédure suivante pour résoudre ce problème : Créer le fichier main.cf dans /var/packages/MailServer/etc/customize/postfix/ (les dossiers soulignés doivent être créés car ils n'existent pas par défaut) Y renseigner les réseaux privés comme suit : mynetworks = 10.0.0.0/8 127.0.0.0/8 172.16.0.0/12 192.168.0.0/16 Redémarrer le paquet Mail Server. L'exemple de configuration ci-dessus autorise tous les réseaux privés, il est évidemment possible de restreindre uniquement aux réseaux ou hôtes utilisés selon le degré de sécurité de l'environnement dans lequel le NAS est intégré. J'utilise ce relai pour faciliter les envois de messages (notifications et rapports des divers équipements) et me suis retrouvé confronté à ce problème. J'espère que Synology intègrera cette modification dans les prochaines mises à jour de Mail Server (même si je n'y crois pas vraiment).

C'est DSM.

Tarègle est bonne, il n'y aurait plus que le pare-feu du NAS qui bloquerait le trafic externe entrant. La liste des points à vérifier (non valable pour les horreurs que sont EZ-Internet, QuickConnect, ...) : Vérifier l'adresse IP (surtout si elle est dynamique). Si un nom de domaine est utilisé, vérifier que l'adresse IP résolue est bonne. Vérifier que le port est bien redirigé vers le NAS dans les règles PAT de la box ou routeur (n° de port, adresse IP privée du NAS). Vérifier l'état du pare-feu du NAS. Vérifier que le service est bien démarré (c'est con, mais ça arrive).

Ça ressemble à un souci de configuration de la règle PAT sur la box (port tcp/5001 injoignable).

Il y a 80% de chances que la migration ne fonctionne pas (DSM trop ancien, plan de partitionnement obsolète, système de fichiers, ...). Le mieux est de sauvegarder les données et de réinitialiser les disques, ça permettra également de bénéficier de BTRFS et d'une partition système avec une taille suffisante.

Est-ce que tu as bien désactivé le Wi-Fi avant de tester ? Quel est le message d'erreur renvoyé par l'application ?

Dans les applications mobiles, il suffit simplement d'entrer le nom du sous-domaine No-IP et les identifiants.

Il faut rediriger le port tcp/5001 vers le NAS dans la configuration de la box/routeur et se connecter en utilisant l'adresse IP publique de la box, et non l'adresse privée du NAS.

C'est un peu élevé 20% de CPU au repos. Quel est le processus qui consomme du CPU au repos ? (probablement DSM lui-même)

Changer le MTU n'apporte que des problèmes sur les protocoles de partage de fichiers courants. C'est principalement réservé aux réseaux SAN iSCSI. C'est très bien, il faut tester en conditions réelles avec les protocoles que tu utilises. Inutile de la désinstaller, l'arrêt de Download Station dans le Centre de paquets est suffisant. Quelle est l'activité du NAS au repos ? (CPU et disque dans le moniteur de ressources, identifier si nécessaire le processus)

Oui, en RAID 1 toute modification de donnée est faite sur les deux disques en même temps. Ce qui veut aussi dire que toute suppression est faite de la même manière et qu'il n'y a aucun moyen de récupérer une donnée supprimée en cas de mauvaise manipulation (comme sur un disque simple). D'où la nécessité de la sauvegarde des données importantes sur un support externe au NAS (clé/disque USB, équipement distant, ...). Ce support ne doit être connecté au NAS que lors d'une sauvegarde ou d'une restauration, mais surtout pas de manière permanente sinon le support devient vulnérable aux attaques (SynoLocker pour ne citer que lui). Le RAID n'assure que la continuité de service (inutile pour 99% des particuliers) mais ne permet pas de restaurer des données perdues contrairement à une sauvegarde. Quelque soit le schéma de configuration des disques choisi (volumes simples, RAID, SHR, ...), la sauvegarde est indispensable si vos données sont importantes. Enfin, le RAID ne se substitue pas à la sauvegarde.

D'après l'aide de DSM : Attention à l'aspect sécurité si les droits sont différents entre l'emplacement du lien symbolique et le contenu ciblé.

Le problème de http://find.synology.com c'est que c'est public (ça ne devrait intéresser personne sur internet qu'un utilisateur cherche son NAS en local), et que la communication n'est même pas chiffrée. À partir de ce constat, je préfère travailler en local (oui, j'ai atteint un degré de paranoïa élevé ).

J'espère que cette solution ne servira pas trop souvent à résoudre les problèmes de mise en route... Sinon pour retrouver l'adresse IP d'un NAS adressé en automatique (configuration par défaut), il suffit d'utiliser Synology Assistant qui est téléchargeable à l'adresse suivante : https://www.synology.com/fr-fr/support/download/.

Ça n'a pas l'air compatible avec DSM 6 pour le moment : http://synopass.deadcode.net/#post-455

Si tu n'as pas de règles PAT configurées dans la Livebox, le pare-feu peut-être désactivé.

Il y a donc déjà une solution en place, tu ne m'avais pas tout dit ! Si tu as d'autres précisions sur l'existant ça peut être intéressant. Si les utilisateurs travaillent déjà sur un espace partagé en réseau, qu'apporterait de plus un NAS ? L'accès à distance peut se faire via un VPN (si la connexion internet a un débit suffisant).

Si le NAS est derrière une ligne ADSL, le problème de débit reste le même.

Il faut au moins prévoir le double de capacité de stockage (12To), un DS916+ avec 3x 6To en RAID 5 ferait l'affaire. 4 disques (4To ou 6To) permettraient d'augmenter les IOPS. C'est fortement déconseillé, en tout cas ce sera plus lent que de travailler en local et les utilisateurs le ressentiront. Tout aussi déconseillé et source de conflits. Ce serait possible avec Cloud Station et les versions multiples, mais personne ne s'y retrouvera.

Il n'y a pas ce genre de désagrément sur un DSM 4.3 et 5.2. Faudra quand même que je me penche sur DSM 6.0 après les beaux jours. Avec un script de nettoyage lancé par une tâche planifiée, ça devrait suffire. Ceci dit ça peut être intéressant en cas d'intervention du support.

Même un switch à 15€ est largement suffisant. Du CAT5e minimum (le "e" est important). En théorie AFP mais dans la pratique AFP se révèle instable. SMB ne pose aucun problème. Il n'y a d'ailleurs pas besoin d'un switch supportant LACP pour agréger des liens, donc un switch à 15€ fera largement l'affaire. Si le Mac n'est pas équipé de deux interfaces réseau agrégées, l'agrégation n'apportera aucune amélioration des performances.

Bravo pour la description de ton environnement de travail et l'expression de tes besoins ! C'est rarement aussi abouti, surtout pour quelqu'un se présentant comme débutant. Il reste quelques points à préciser : Comment sont reliés les postes au réseau ? (câble, Wi-Fi, ..) Quels sont les types (xDSL, Fibre, ...) et débits des connexions internet utilisées ? (atelier et domicile) Quel sont les principaux types et la taille des fichiers échangés ? Depuis quels appareils seront faits les accès à distance ? (PC, smartphone, tablette, ...) Ne pas oublier un onduleur pour préserver les données des risques de coupures/pannes électriques.

Ce que dit Gaetan concernant le choix du système de fichiers est vrai dans le cas général, mais seules les architectures x64 sont supportées pour le moment. Ce qui peut surprendre en voyant que certains modèles comme le DS2015xs (ARM) qui ne sont pas supportés. Source : https://www.synology.com/fr-fr/dsm/Btrfs#applied_models