Classement

1. Préambule Ce tutoriel a pour but d'autoriser l'accès aux données du NAS via le protocole SMBv1 (ou NT1) sans pour autant impacter le niveau de sécurité d'accès au NAS. Cela permet d'assurer la compatibilité d'équipement qui n'auraient pas été mis à jour par leur fabricant. SMBv1 est un protocole déprécié et comportant des failles de sécurité. Lorsqu'il est possible de vous en passer, faites-le. 2. Prérequis Avoir un NAS compatible Docker, voir la liste ici. Savoir se connecter au NAS via SSH en root : Utiliser Docker-compose Avoir installé le paquet SynoCLI File Tools, pour ajouter le dépôt SynoCommunity voir la partie Easy Install sur cette page. IMPORTANT : Si vous souhaitez accéder aux dossiers partagés "music", "video", etc... à la racine tels quels, ça ne pourra pas fonctionner, il faudra monter des sous-dossiers de ces dossiers partagés. Autant prévenir de suite. 3. Principe Afin de ne pas devoir réduire drastiquement le niveau de sécurité du NAS en autorisant le protocole SMBv1, on va passer par un conteneur qui va monter uniquement les fichiers du NAS dont on a besoin, et qui lui, autorisera l'accès en SMBv1. Comme le NAS utilise déjà le port 445 pour parler SMB avec les autres périphériques du réseau, il n'est pas disponible, on va donc utiliser un réseau macvlan (voir point 11-A de mon tutoriel introductif à Docker). Ce réseau permet entre autre d'attribuer au conteneur une IP située sur le même sous-réseau que votre réseau local. En somme, il devient accessible comme n'importe quelle autre machine, avec une IP par exemple du 192.168.0.x. Comme il est fréquent de faire avec des machines virtuelles. Cela permet notamment d'utiliser des ports déjà utilisés sur le NAS, et facilite la détection par les autres appareils, car visible directement par tout le réseau. 4. Mise en place du réseau macvlan Je ne détaille pas cette étape, car elle est décrite avec précision au point 11-A-1 du tutoriel introductif. A noter dans ce tutoriel précis qu'il n'est pas nécessaire de mettre en application le point 11-A-2 qui s'attarde sur la création d'une interface virtuelle pour communiquer entre le NAS et le conteneur. Si vous avez déjà un réseau macvlan disponible, assurez-vous simplement de disposer d'une IP libre dans la plage utilisée. Et adaptez les hypothèses suivantes. 5. Hypothèses Je vais me baser sur la plage et le sous-réseau utilisés dans le tutoriel introductif : IP hôte (NAS) : 192.168.0.100 Passerelle : 192.168.0.1 Sous-réseau local : 192.168.0.0/24 (ou encore écrit 192.168.0.0/255.255.255.0) Plage macvlan : 192.168.0.144/28 (vous pouvez vérifier les IP que ça concerne ici : http://jodies.de/ipcalc) IP conteneur : 192.168.0.145 Les valeurs en orange sont directement héritées de la mise en place du réseau macvlan, et sont simplement répétées par rapport au tutoriel introductif dans un souci de contextualisation. Les valeurs en vert sont propres à votre installation et ce tutoriel. 6. Configuration 6-A. Fichier docker-compose On va créer le fichier docker-compose.yml qui va reprendre toute la configuration de notre conteneur. On va utiliser l'image servercontainers/samba. Elle met à disposition un serveur Samba entièrement configurable, accompagné d'Avahi et WSD pour qu'il s'annonce sur le réseau et le rendre consultable et visible dans Finder (Mac) et l'explorateur Windows. Il faut savoir que cette image a été améliorée suite à des propositions que j'ai faites à son créateur. Elle a été adaptée pour faciliter la compatibilité avec DSM et sa version particulière de Linux. Tout d'abord, on se connecte en SSH en root, puis on crée le dossier qui va contenir la configuration du conteneur mkdir -p /volume1/docker/samba/ && cd $_ mkdir conf On va ensuite créer le fichier docker-compose.yml en utilisant nano (ou le télécharger ici : docker-compose.yml et l'importer dans File Station au bon endroit). nano docker-compose.yml dont voici un modèle : version: '2.1' services: samba-nt1: image: servercontainers/samba container_name: samba-nt1 hostname: samba-nt1 networks: mac0: ipv4_address: 192.168.0.145 environment: ## Groups ## - GROUP_users=100 ## Accounts ## - ACCOUNT_media=motdepassemedia - UID_media=10XX - GROUPS_media=users ## Global variables ## - SAMBA_GLOBAL_CONFIG_server_SPACE_min_SPACE_protocol=NT1 - SAMBA_GLOBAL_CONFIG_ntlm_SPACE_auth=ntlmv1-permitted - SAMBA_CONF_MAP_TO_GUEST=Never ## Shares ## - SAMBA_VOLUME_CONFIG_music=[music]; path=/shares/music; guest ok = no; read only = yes; browseable = yes; valid users = media; force group = users volumes: - /volume1/music/bibliotheque:/shares/music - /volume1/docker/samba/conf:/etc/samba restart: unless-stopped networks: mac0: external: true 6-B. Personnalisation des paramètres 6-B-1. Général Dans un fichier docker-compose, il n'y a pas de tabulation, uniquement des espaces, et il est important de respecter l'indentation (l'alignement). Les sauts de lignes ou le nombre d'espaces que vous mettez pour décaler les items n'a en revanche aucun impact, assurez-vous juste que ce soit lisible. hostname : cette variable est importante ici car c'est le nom que vous verrez apparaître dans la découverte de réseau de Windows. Cette chaine de caractères est automatiquement convertie en majuscules sous Windows, évitez les caractères exotiques. ipv4_address : c'est l'adresse IP que j'attribue manuellement au conteneur, c'est la première disponible dans la plage que j'ai choisie pour mon réseau macvlan nommé mac0. GROUP_users : On va définir au sein du conteneur un group "users", celui-ci correspond au groupe auquel appartient naturellement votre/vos utilisateur(s) du NAS. On lui donne la valeur de 100 car c'est le gid du groupe users sur DSM également. Si pour une raison ou un autre vous utilisez un groupe personnalisé, vous devez déterminer le GID affilié à ce groupe. Pour cela, tapez en SSH : cat /etc/group | grep nom_du_groupe Il faudra utiliser le nombre à la fin de la ligne en sortie de commande. ACCOUNT_media, UID_media et GROUPS_media : Voir paragraphe 6-B-3. SAMBA_GLOBAL_CONFIG_server_SPACE_min_SPACE_protocol : En lui donnant une valeur NT1 on autorise SMBv1 comme protocole minimal, depuis Samba 4.x le protocole minimal est SMB2. NT1 est le nom officiel de SMBv1. SAMBA_GLOBAL_CONFIG_ntlm_SPACE_auth : Il faut également autoriser l'authentification NT1. SAMBA_CONF_MAP_TO_GUEST : On ne souhaite pas que les utilisateurs soient automatiquement redirigés sur guest en cas de mauvais nom d'utilisateur ou de mot de passe. Donc on désactive la directive. SAMBA_VOLUME_CONFIG_music : voir 6-B-4. volumes : voir 6-B-2. restart: unless-stopped : Le conteneur redémarre quand il s'arrête suite à une erreur, si le service Docker ou le NAS redémarrent. Sauf si on l'a arrêté manuellement. networks : Je dois définir la nature du réseau mac0 invoqué plus haut pour le paramètre ipv4_address. Il a été créé extérieurement au conteneur, ce que je précise par le paramètre external: true. 6-B-2. Volumes Pour revenir au point abordé dans les pré-requis, et sans rentrer dans les détails, l'utilisation de cette image avec DSM possède quelques limitations : Il n'est pas possible de monter directement un dossier partagé à la racine : par exemple dans mon fichier docker-compose, je monte /volume1/music/bibliotheque et pas /volume1/music dans /shares/music. Cela vient des permissions UNIX qui sont inexistantes au niveau des dossiers partagés du point de vue de l'utilisateur root, c'est la surcouche d'ACL qui gère les permissions. Par conséquent, les permissions UNIX doivent être suffisantes pour garantir un fonctionnement adéquat. Prenons un exemple : ls -l /volume1/music Les permissions UNIX pour le dossier "bibliotheque" par exemple sont définies par les caractères qui se situent à gauche du "+" : drwxr-xr-x. Cas d'utilisation : Pour traverser les dossiers et lire en lecture seule avec un utilisateur authentifié, il faut a minima : dr-x------ pour un dossier (-r-x------ pour un fichier). Pour traverser les dossiers et lire/écrire avec un utilisateur authentifié, il faut a minima : drwx------ pour un dossier (-rwx------ pour un fichier). NON RECOMMANDÉ : Pour traverser les dossiers et lire en lecture seule avec un utilisateur guest (non authentifié), il faut a minima : d------r-x pour un dossier (-------r-x pour un fichier). NON RECOMMANDÉ : Pour traverser les dossiers et lire/écrire avec un utilisateur guest (non authentifié), il faut a minima : d------rwx pour un dossier (-------rwx pour un fichier). Je ne recommande pas les deux derniers cas d'utilisation, car SMBv1 est un protocole déprécié et ayant des failles de sécurité. Or SMB de manière générale est sûrement le moyen le plus simple d'infecter un NAS. Néanmoins, cela peut avoir son utilité par exemple pour des imprimantes d'ancienne génération, qui stocke des éléments scannés dans un répertoire du NAS via SMBv1. L'utilisation d'un guest doit rester exceptionnelle. NOTE : Avoir d------rwx n'implique pas qu'un guest aura forcément accès aux données du partage, on peut tout à fait désactiver l'accès guest par la configuration du partage (voir point 6-B-4), limiter l'accès à certains partages à certains utilisateurs uniquement, etc... c'est simplement une condition nécessaire, mais non suffisante. En revanche, si vous n'avez pas ces permissions a minima, activer le guest n'aura aucun effet. Voilà un type de montage qu'on pourrait vouloir faire : volumes: - /volume1/music/bibliotheque:/shares/music - /volume1/video/films:/shares/films - /volume1/video/series:/shares/series - /volume1/famille/documents:/shares/documents On doit aussi s'assurer d'avoir monté le dossier dans lequel se trouvera le fichier de configuration smb.conf créé par le conteneur lors de sa mise en route : - /volume1/docker/samba/conf:/etc/samba 6-B-3. Utilisateur Pour faciliter le bon fonctionnement du conteneur, il est recommandé de créer des utilisateurs dont le nom existe déjà dans DSM. Dans mon cas, j'ai un utilisateur media qui est propriétaire de tous les fichiers multimédias (musique et vidéo). ls -l /volume1/music/bibliotheque Au sein d'un même partage (par exemple le contenu musical), il est recommandé qu'un seul et même utilisateur soit propriétaire de tous les fichiers. Ca ne changera rien dans DSM car le système a sa propre couche d'ACL qui détermine les permissions de chacun, et ça facilitera l'exploitation du conteneur. Pour unifier le propriétaire d'un ensemble de fichiers et dossiers, c'est très simple, on va dans File Station, on sélectionne les éléments dont on souhaite changer la propriété, clic droit, Propriétés. En bas de la fenêtre, on choisit le propriétaire. Si on a sélectionné un dossier, on peut cocher la case "Appliquer à ce dossier, ses sous-dossiers et ses fichiers" pour que les enfants héritent du même propriétaire. NOTE : Si vous sélectionnez à la fois des dossiers et des fichiers, il se peut que le cadre Propriétaire n'apparaisse pas. Limitez votre sélection et ça marchera. Je vais donc créer un utilisateur media dans le conteneur via la variable d'environnement : ACCOUNT_media. La valeur de cette variable est le mot de passe pour l'utilisateur media dans ce conteneur. NOTE : Ce mot de passe ne doit pas être le même que celui pour l'utilisateur media du NAS ! En effet, le conteneur aura ses propres accès. La documentation de cette image permet de chiffrer ce mot de passe, pour ma part je n'en vois pas l'intérêt. Car pour accéder à ce fichier, l'utilisateur doit déjà avoir infecté le NAS. Cacher ses clés dans la maison n'a pas d'intérêt s'il y a déjà effraction. Concernant la variable UID_media, il s'agit de l'ID de l'utilisateur. Il est pratique d'utiliser le même UID que celui de l'utilisateur du NAS. Pour récupérer cet UID, il suffit de taper en SSH : id media Dans mon cas c'est 1035, dans tous les cas c'est strictement supérieur à 1025. Enfin, pour GROUPS_media, on lui donne la valeur users, par défaut l'utilisateur appartient à un groupe identique à son nom d'utilisateur. Pour DSM, le groupe users est le groupe par défaut pour les utilisateurs. On s'assure une meilleure compatibilité avec les ACL. Au final, en configurant ces trois variables, on assure la création d'un utilisateur qui pourra se servir des droits utilisateurs accordés par les permissions UNIX et ne fâchera pas les ACL de DSM. REMARQUE : Il est tout à fait possible de créer plusieurs utilisateurs, par exemple si vous décidez de monter l'espace personnel d'un utilisateur du NAS, ou simplement parce que tous les fichiers de vos partages n'appartiennent pas à un seul et même utilisateur. Exemple : - ACCOUNT_media=motdepassemedia - UID_media=1035 - GROUPS_media=users - ACCOUNT_lolita=motdepasselolita - UID_lolita=1031 - GROUPS_lolita=users 6-B-4. Configuration des partages La configuration des partages se fait via la variable d'environnement SAMBA_VOLUME_CONFIG_music (pour un partage qui se nommerait "music"). La valeur associée peut paraître étrange avec ses points virgule, mais ça représente juste un saut de ligne dans ce qui correspond habituellement à la configuration d'un partage SMB. Voyons plus en détail : path=/shares/music : correspond à l'emplacement qu'on a indiqué dans le montage de volume, c'est le chemin DANS le conteneur. [music] : c'est le nom du partage tel que vous le verrez dans votre explorateur. Vous pouvez utiliser des majuscules et des espaces ici. guest ok : prend la valeur "yes" ou "no", dans le premier cas lorsque vous vous connecterez aucun mot de passe ne vous sera demandé. Valeur recommandée : no. read only : est assez explicite, prend la valeur "yes" ou "no". En SMBv1, préférez la lecture seule. browseable : permet de voir apparaître le partage dans les onglets de découverte du réseau. valid users : permet de définir quel(s) utilisateur(s) sont autorisés à accéder au partage. Pour ajouter plusieurs utilisateurs, les séparer par une virgule. Si tous les utilisateurs peuvent accéder au partage, il n'est pas nécessaire d'utiliser cette directive. force group : Par défaut, ce sera l'utilisateur media/media qui écrira quand on est connecté avec cet utilisateur, on souhaite que le groupe par défaut soit users, d'où la valeur forcée à "users" pour ce paramètre. Autres directives majeures disponibles : comment : permet de décrire notre partage, majuscules autorisées. directory mask : permet de définir quelles seront les permissions UNIX par défaut lors de la création d'un dossier. Exemple : create directory mask = 0755 => les dossiers auront les permissions suivantes : drwxr-xr-x. Voir la page Wikipédia (Fonctionnement - Représentation des droits) pour plus d'information : https://fr.wikipedia.org/wiki/Permissions_UNIX create mask : même chose pour un fichier. guest only : nécessite d'avoir réglé guest ok sur "yes" au préalable. Accès guest seulement (pas d'authentification). Il existe énormément de paramètres configurables pour un partage SMB, voir la liste ici : https://www.samba.org/samba/docs/current/man-html/smb.conf.5.html Tout est maintenant configuré. On n'a plus qu'à sauvegarder le fichier docker-compose (sous nano, CTRL+O puis Entrée pour sauvegarder, CTRL+X pour sortir de l'éditeur). 7. Création du conteneur Pour créer le conteneur, on vérifie qu'on se trouve toujours dans /volume1/docker/samba et on tape : docker-compose pull Ce qui va télécharger la dernière version de l'image. Puis : docker-compose up -d Si pas d'erreur à la création (souvent dues à des caractères de tabulation, une directive dans le fichier docker-compose mal orthographiée ou désalignée, etc...), vous verrez un petit done apparaître en vert. Si browseable a été activé, on voit le partage dans la découverte réseau : Tous les autres moyens habituels pour accéder à un partage SMB sont actifs (connecter un lecteur lecteur réseau, smb:// via Finder, etc...). MàJ : 13/01/2022

Un petit tuto rapide pour vous indiquer les étapes à effectuer lors du remplacement d'un disque dur sur un NAS avec 2 disques en SHR, la procédure est la même pour le raid1, le raid5, le raid6 et le SHR2. ######################## Mon DS712+ était monté en SHR avec un disque de 3To et un disque de 4To => 3To de disponibles. Comme il commençait à être très rempli (moins de 1% d'espace disponible) et que j'avais un disque de 4To en spare, j'ai décidé de lui donner un peu d'air. C'était l'occasion de vous faire les captures d'écran des différentes étapes à réaliser. nb : vous l'aurez compris, ici je n'ai pas eu de panne disque, je souhaitais juste augmenter l'espace disponible, mais les premières étapes sont les mêmes. ######################## Tester le disque en spare Il est recommandé de tester les disques avant de les utiliser, il existe plusieurs manières de faire. Certains recommandent d'utiliser les outils du constructeurs, d'autre de faire un formatage de bas niveau et les derniers d'utiliser le programme badblock présent sur les Synology. Je n'ai pas de méthode préférée, chacun fait comme il veut, l'important est de s'assurer de ne pas installer un disque défaillant. ######################## Identifier le disque à remplacer Afin d'être certain de retirer le bon disque (enfin celui qui est mauvais ), surtout si les disques sont du même modèle, le plus fiable est de relever le numéro de série dans le Gestionnaire de stockage : Ici les 2 disques sont sains, pour la suite on va dire que le disque 2 était en panne, donc je relève son numéro de série. On peut aussi se fier à la numérotation des disques (vous trouverez des exemples dans les commentaires), mais l'utilisation du numéro de série ne devrait pas laisser de place au doute. ######################## Vérifier que les sauvegardes sont à jour Comme toujours, il faut s'assurer d'avoir des sauvegardes des données du NAS, on n'est jamais à l'abri d'un problème, surtout en cas de reconstruction d'un raid comme ici. La réparation d'un volume est une opération assez intense pour les disques. ######################## Couper proprement le NAS Certains NAS permettent le remplacement d'un disque à chaud (c'est le cas des miens), mais si c'est possible, il vaut mieux éteindre proprement le NAS et débrancher son cordon secteur pour faire la manipulation. ######################## Remplacer le disque à changer On retire le disque à changer et on contrôle que c'est bien lui grâce au numéro de série. Il serait dommage de retirer le disque qui fonctionne. C'est un des avantages de faire la manipulation NAS coupé : si on retire le mauvais disque (enfin celui qui va bien ), il suffit de le remettre à sa place. On insère le nouveau disque dans son emplacement et on rallume le NAS. nb : si votre disque était stocké dans un endroit froid (en hiver dans le garage par exemple), attendez qu'il soit revenu à température ambiante avant d'allumer le NAS, dans le cas contraire, la dilatation des composants (plateaux et têtes de lecture) risque de l'endommager définitivement. ######################## Volume dégradé Au démarrage (qui sera peut être un peu plus long que la normal), votre NAS va se mettre à biper. En vous connectant à l'interface, le Gestionnaire de stockage et le Panneau de configuration vont s'ouvrir. Le panneau de configuration vous servira juste à couper le bip s'il est gênant. Dans le gestionnaire de stockage vous aurez quelque chose comme ceci : Comme indiqué dans le message, le nouveau disque doit avoir une taille minimale (ici il doit faire au moins 2794 Go). Notez en passant le taux de remplissage. Ne laissez pas votre NAS se remplir autant, c'est mal, ça ralenti tout le système et ça peut même créer des pannes (ça faisait très longtemps que je devais m'occuper de ça, j'ai trop trainé). Ici vous devez cliquer sur le bouton Gérer (suivez la flèche). ######################## Réparation du volume Un nouvel écran apparait, il vous propose de Réparer le volume : Lisez le message (contrairement à ce que j'avais fait, je viens de m'en rendre compte en me relisant), validez le choix et faites Suivant. Le NAS vous indique le disque qu'il va utiliser pour faire cette réparation (c'est le nouveau disque). Choisissez le disque à utiliser (ici je n'ai pas le choix) puis faites Suivant. Le NAS vous rappel une dernière fois que le disque sélectionné sera effacé : Si vous êtes certain d'avoir choisi le bon disque, validez avec OK Vérifiez que tout est conforme puis appliquez la configuration avec le bouton Appliquer. ######################## Contrôle de l'avancement Dans le gestionnaire de volume, vous pourrez contrôler l'avancement de la réparation : Si vous avez configuré les notifications, vous recevrez ceci : Puis ceci : À partir de ce moment, même si ce n'est pas recommandé, vous pourrez utiliser votre NAS normalement, même l'éteindre si besoin (la réparation recommencera au démarrage suivant). Par contre toutes les opérations seront fortement ralentis. Je vous recommande de laisser le NAS faire sa réparation tranquillement (ce n'est pas le moment d'aller y recopier des Giga de données). ######################## Contrôle de l'avancement en SSH Si vous souhaitez avoir plus de détails sur l'avancement de la réparation, connectez vous en ssh et entrez la commande : cat /proc/mdstat fenrir@nas:~$ cat /proc/mdstat Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] md2 : active raid1 sdb5[2] sda5[3] 2925531648 blocks super 1.2 [2/1] [U_] [>....................] recovery = 2.7% (79955328/2925531648) finish=614.9min speed=77126K/sec md1 : active raid1 sdb2[1] sda2[0] 2097088 blocks [2/2] [UU] md0 : active raid1 sdb1[1] sda1[0] 2490176 blocks [2/2] [UU] unused devices: <none> Ici la vitesse est cohérente par rapport au taux de remplissage de mon NAS, à sa charge et à la vitesse des disques. ######################## Accélérer la vitesse de réparation La reconstruction d'un raid c'est toujours long, surtout avec des disques de plusieurs To et avec les raid de parité (raid5 ou 6) c'est encore plus long, donc il faut prendre son mal en patience. Avec mes 2 disques de 4To, mon NAS m'annonce environ 10h, il va bosser toute la nuit. La meilleur des actions à effectuer consiste à ne rien faire sur le NAS : laissez le tranquille. Néanmoins, dans certains cas, il arrive que la vitesse soit anormalement basse, il peut y avoir 3 causes : l'un des disque est fatigué ou défaillant : comme indiqué précédemment, la reconstruction d'un raid est une opération lourde pour les disques, d'où l'importance des sauvegardes votre NAS est trop sollicité : coupez les applications non essentiels, mettez vos téléchargement en pause, reportez votre soirée ciné ... la réparation est bridée Pour le dernier cas, il faut vérifier les 3 valeurs suivantes : La vitesse en dessous de laquelle la réparation ne doit pas aller (par défaut c'est 10000) : cat /proc/sys/dev/raid/speed_limit_min La vitesse au dessus de laquelle la réparation ne doit pas aller (par défaut c'est 200000) : cat /proc/sys/dev/raid/speed_limit_max La vitesse maximal autorisée dans la limite de la valeur précédente (par défaut c'est "max") cat /sys/block/md?/md/sync_max Si vous constatez des valeurs différentes chez vous, postez le résultat sur le forum, on vous indiquera si oui ou non c'est normal et si vous devez ou non modifier ces valeurs. ######################## Résultat final Une dernière notification pour indiquer que l'opération est terminée : Au final l'opération aura pris 12h chez moi, par contre je ne m'attendais pas à ça (mais j’aurais du puisque c'était indiqué dans le message dès le début) : Mon Syno a décidé tout seul d'agrandir le volume agrandi le volume comme annoncé, sans aucune intervention de ma part (je pense qu'il a fait ça en 2h, après les 10h estimées pour la réparation du raid). On appréciera ou non, perso, même si c'est ce que je comptais faire, j'aurai préféré qu'il laisse le choix (pour créer un nouveau volume par exemple). En pratique il a créé un nouveau volume physique LVM (pv) qu'il a associé au groupe (vg) afin d'agrandir le volume logique (lv) : fenrir@nas:~$ cat /proc/mdstat Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] md3 : active raid1 sdb6[1] sda6[0] 976646528 blocks super 1.2 [2/2] [UU] md2 : active raid1 sdb5[2] sda5[3] 2925531648 blocks super 1.2 [2/2] [UU] md1 : active raid1 sdb2[1] sda2[0] 2097088 blocks [2/2] [UU] md0 : active raid1 sdb1[1] sda1[0] 2490176 blocks [2/2] [UU] unused devices: <none> On voit bien l'apparition de md3 (environ 1To).