PierU

Ca a marché avec un utilisateur vierge. Dans le compte problématique j'ai lancé l'exécutable à la main et ai vu un message d'erreur qui ressemblait à l'impossibilité de créer le dossier "~/.SynologyDrive". En vérifiant les permissions du dossier "~" j'ai constaté que la permission write du propriétaire avait sauté ! Je ne sais pas comment ça a pu arriver, mais bon... En restaurant cette permission tout fonctionne !

Ici il est indiqué que la version 3.1.0-12920 est la dernière à supporter 10.13, alors que la version la plus récente est 3.1.0-12923 : https://www.synology.com/fr-fr/releaseNote/SynologyDriveClient Bon, peu importe... En essayant sur l'iMac, ce dossier se crée au premier lancement du lancement, même sans connexion. Mais sur le MBP il plante visiblement dès le lancement, avant même de créer le dossier. J'ai dû le faire 10 fois entre les différentes versions 🙂 Je suppose que quand on met à jour il installe la dernière version disponible, mais il faut je vérifie (je n'ai pas le MBP sous la main là tout de suite). J'essaierai aussi en créant un utilisateur vierge pour voir.

Oui c'est ce que j'ai écrit : après vérification j'ai lu ça. Il le vérifie peut-être au lancement pour afficher un message, mais le problème c'est qu'il n'arrive même pas à ce stade... Ce serait mieux qu'il écrivent les specs requises sur la page de download sans qu'il y a ait besoin d'aller consulter les notes de versions, mais bon c'est un détail. De toutes au final le problème n'est pas là, vu que ça ne marche pas non plus avec tout à jour (OS et client), et je l'ai mentionné juste pour l'historique des manipes.

Bonjour, J'utilise depuis 2 ans le client Synology Drive sur un iMac 2011 sous macOS 10.13 (High Sierra), sans aucun souci. J'essaye maintenant de l'installer sur un Macbook Pro 2015, mais impossible de l'utiliser, il ne démarre même pas. Au départ j'avais téléchargé la dernière version du client. Après vérification j'ai vu qu'elle ne supportait plus macOS 10.13, qui était installé aussi sur le MBP. Je télécharge alors la même version que celle qui est sur l'iMac (3.0.3-12689) pour être sûr. Mais ça ne change rien. Je décide alors de mettre à jour le MBP vers macOS 12 (Monterey), et de réinstaller la toute dernière version du client : toujours rien ! Après l'installation, ou quand j'essaie de le lancer manuellement, je vois une fenêtre furtive du genre "Synology Drive Client is initializing", plus plus rien... Aucune icône dans la barre supérieure. En cherchant un peu je vois que dans le dossier home de l'utilisateur il devrait exister un dossier ".SynologyDrive" : c'est bien le cas sur l'iMac, mais pas sur le MBP... Impossible de trouver la moindre piste... Une idée ? Merci

Oui. Je me comprends : on ne peut plus se connecter directement comme root, comme indiqué dans le tuto d'origine. Il faut passer par sudo, que ce soit commande par commande ou comme tu l'indiques.

Je viens de faire la manipe, elle a parfaitement fonctionné (aux sudo près qu'il faut ajouter devant les commandes, vu qu'on ne peut plus se connecter en root dans DSM6) ! EDIT : juste pour info, est-ce qu'elle est généralisable à des cas de grappes SHR plus grandes ? Par exemple pour passer de 3 à 2 disques ?

Même en admettant, faut-il encore que l'augmentation de fiabilité justifie la différence de prix. De toutes façons ce débat est en train de tourner court, vu que les disques "tout-venant" de grosses capacités pour PC sont de plus en plus des disques SMR. Plus vraiment d'autre choix que de se tourner vers des disques pour NAS du coup.

Question complémentaire : que fait le test SMART étendu ? Vu le temps qu'il dure, est-ce que justement il ne tente pas de lire tous les secteurs ?

En effet, en ext4 ET avec moins de 3 disques il n'y a pas : https://www.synology.com/fr-fr/knowledgebase/DSMUC/help/DSMUC/StorageManager/storage_pool_data_scrubbing

@oracle7 Je n'ai rien de tel à cet endroit (ni dans le sous menu "Action" ni dans l'onglet "Configurations") : https://i.imgur.com/wF53joM.png

Bonjour, Le tests "IronWolf Heath Management" est-il complémentaire du test SMART étendu, ou bien peut-on complètement se passer du test SMART étendu si on programme le test IHM ?

Je remonte ce vieux topic : où se trouve cette option de "nettoyage" dans DSM ? Je ne trouve pas...

La commande cat /proc/mdstat me donne ça : Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] md2 : active raid1 sda5[1] sdb5[0] 3902187456 blocks super 1.2 [2/2] [UU] md1 : active raid1 sda2[1] sdb2[0] 2097088 blocks [2/2] [UU] md0 : active raid1 sda1[1] sdb1[0] 2490176 blocks [2/2] [UU] Est-ce que sda c'est forcément le Drive 1 dans DSM, et sdb le Drive 2 ? Je me demande car initialement j'avais mis un disque unique, mais dans l'emplacement du Drive 2 (l'emplacement du Drive 1 étant inoccupé). Comment voir les caractérisques de sda et sdb (df ou /etc/fstab ne montrent que les volumes logiques, pas les disques physiques) ?

@maxou56 OK (oui admin plutôt)

@jorgemarmo tu as essayé cette manipe ? ça a marché ? Ou quelqu'un d'autre a essayé ? J'ai fait aussi l'erreur d'enrôler le deuxième disque que j'ai mis dans mon DS218j dans le groupe SHR qui était initialement sur le premier disque. A la réflexion 90% des données qui sont sur mon NAS n'ont aucun besoin de redondance (je les ai ailleurs, ou ce sont déjà des backups... en cas de panne d'un disque je peux les restaurer à la main une fois le disque changé... Et pour les 10% des données qui ont besoin de redondance, je peux faire un backup régulier d'un disque sur l'autre). J'ai désactivé root (je ne sais même plus quel est le mot de passe 🤔) mais j'ai créé un utilisateur qui a les droits d'administration : je suppose que je peux l'utiliser à la place de root pour les manipes décrites dans le lien ? Peut-être à coup de sudo ?

Il me semble que le problème est le même que sur les SSD. Ce que je comprends du SMR c'est qu'il est impossible d'écrire sur une piste sans écraser les pistes voisines. Genre sur 10 pistes voisines (je prends des nombres au hasard !), écrire sur la piste 1 écrase les pistes 2 et 3, écrire sur la piste 2 écrase les pistes 3 et 4, etc... Toutes les 10 pistes il y a 2 pistes inutilisées, de sorte qu'écrire sur la piste 10 n'écrase jamais aucune données sur les pistes 11 et 12 (par contre les pistes 13 à 22 contiennent à nouveau des données). Donc si on veut écrire sur la piste 4 : si les pistes 5 & 6 sont vides pas de problème si les pistes 5 & 6 ne sont pas vides il faut d'abord les lire et les stocker ailleurs (petite RAM j'imagine), écrire la piste 4, puis réécrire les pistes 5 et 6... Mais si les pistes 7 et 8 ne sont pas vides, même punition, il faut les lire avant, puis les réécrire (et éventuellement les pistes 9 et 10 pour la même raison). Bref, dans un bloc de 10 pistes l'écriture d'une piste peut conduire à devoir lire jusqu'à 9 autres pistes pour les réécrire ensuite. C'est très similaire à ce qui se passe pour un SSD. Donc on peut imaginer que comme dans un SSD il y ait un garbage collector qui déplace les données, genre si dans un bloc de 10 pistes il y en a 6 qui occupées, et dans un autre bloc il y en 4 d'occupées, il va déplacer les 10 pistes dans un autre bloc unique et libérer complètement les deux blocs initiaux, qui seont ainsi prêt à recevoir des écritures sans avoir besoin d'être relu avant. EDIT : mais bon, je doute qu'il y en ait un en réalité. Je suppose que le fabricants estiment que le cache CMR suffit à avoir des écritures "performantes" 99% du temps pour un usage non intensif.

Bonjour, Certains disques SMR acceptent les commandes TRIM, ce qui m'amène deux questions : 1) Est-ce que DSM permet d'activer le TRIM pour ces disques de la même façon que pour les SSD ? 2) Est-ce que le TRIM peut être un palliatif acceptable pour un disque SMR dans un NAS à usage domestique ? Les seuls moments d'écritures aléatoires intensives que ce NAS fait ce sont les sauvegardes Time Machine (mais pour des Mac qui ne sont qu'occasionnellement sur le réseau local). Je comprends bien que pour une reconstruction RAID le TRIM ne servira pas à rien, cela dit, c'est plus pour le fonctionnement quotidien. Et une question complémentaire : le TRIM sert surtout s'il y a un garbage collector derrière. Mais le garbage collector ça fait de la fragmentation... Sur un SSD on s'en fout largement, mais sur un HDD pas vraiment ! Mais y a-t-il un garbage collector sur les HDD SMR ? Un RAID-1 (et encore moins un RAID-0 comme dit plus loin) ne remplace pas une sauvegarde. Et une sauvegarde locale sur un disque USB (comme suggéré plus loin aussi) ne remplace pas une sauvegarde en ligne (Backblaze ou autre). La sauvegarde en ligne protège les données des sinistres qu'on peut subir chez soi (feu, cambriolage...).

Oui j'avais vu, mais je trouve ça tellement bizarre que je voulais confirmation. Oui, pas idiot. Je vais voir ça.

Bonjour, Suite à cette discussion https://www.nas-forum.com/forum/topic/63316-ajout-dun-disque-plus-petit-et-shr/ J'aimerais en avoir le coeur net sur le point suivant : J'ai commencé avec un seul disque de 4To dans un Syno 2 baies, en créant d'emblée un groupe de stockage SHR. Si j'ajoute un disque de 6To, je peux étendre le groupe SHR sur ce disque (donc avoir 4To de stockage avec redondance de 1 disque), et j'imaginais pouvoir créer un groupe de stockage sur les 2To restant. Mais selon @Mic13710 : "Non, c'est absolument impossible. L'espace n'est tout simplement pas utilisable tant qu'il n'y aura pas un autre disque dont la capacité permettrait de l'utiliser pour former un nouvel espace RAID. " Cela ne me semble pas logique : avec un seul disque j'ai pu créer un groupe de stockage SHR sur un disque unique, "en attente" d'un second disque. Mais il serait impossible de faire la même chose sur le second disque ?

Ah flute 😞 ... Ce n'est encore pas totalement souple leur histoire... Non, c'est absolument impossible. L'espace n'est tout simplement pas utilisable tant qu'il n'y aura pas un autre disque dont la capacité permettrait de l'utiliser pour former un nouvel espace RAID.  Ah bon ?? C'est idiot ça... On peut créer un groupe de stockage SHR sur un disque unique quand il n'y a qu'un disque, mais pas quand il y a deux disques ? En gros si je mets autre chose qu'un deuxième disque de 4To, soit je ne peux rien en faire soit je perds de l'espace.

Bonjour, De ce que j'ai compris de SHR quand on a deux disques de tailles différentes : on peut créer une groupe de stockage SHR qui regroupe les deux disques (équivalent RAID 1), et qui fait la taille du plus petit disque on peut créer un deuxième GS sur l'espace restant du plus gros disque Mais comment fait-on si on ajoute après coup un disque plus petit que le premier ? Situation initiale avec 1 disque de 4To: GS 1 sur disque 1, contenant 5 volumes de taille totale 3To Situation à laquelle je voudrais arriver avec le disque 1 de 4To et un disque 2 de 1To: GS1 sur disque 1, contenant 5 volumes de taille 3To (pas de changement) GS2 en SHR sur disques 1+2, contenant 1 volume de 1To Mais pas moyen... Quand j'essaie de créer un nouveau GS il ne me propose que le disque 2, pas le disque 1. Comme s'il considérait qu'il était plein. A la création du GS1 sur le disque 1 je ne me souviens pas avoir indiqué une taille, DSM l'a dimensionné par défaut au max du disque (4To). Est-il possible de réduire sa taille après coup, sachant que la somme des tailles des volumes ne fait que 3To (et moins de 2To réellement occupés) ? Merci

Oui enfin, il y a quand même des comportements incohérents dans cette histoire. 1) si on crée un dossier directement sur le dossier partagé ce sont les permissions DSM du dossier partagé qui sont appliquées, alors que si on copie un dossier ce sont les permissions unix d'origine. 2) avec SMB/AFP ce sont dans tous les cas les permissions DSM du dossier partagé qui sont appliquées et seulement elles : mais ce n'est pas le comportement obligé de SMB/AFP, qui normalement tiennent compte aussi des permissions locales. C'est le choix de Synology de faire fonctionner SMB/AFP de cette façon, et ils auraient pu l'appliquer aussi à NFS. L'impression que ça me donne c'est que l'intégration de NFS à DSM n'est pas aussi complète que celle de SMB/AFP (en tous cas avec les options utilisées ici)

Bien, j'ai regardé : Sur le montage NFS du dossier partagé, depuis le Mac : dans le Finder je crée un nouveau sous-dossier, et je regarde ensuite ses permissions dans File Station : ce sont les "bonnes", telles que définies pour le dossier partagé dans DSM toujours dans le Finder je copie des dossiers/fichiers du Mac vers le dossier partagé : dans ce cas, leurs permissions sont les permissions unix que ces fichiers avaient sur le Mac, sans aucun lien avec les permissions du dossier partagé ! Déjà le comportement n'est pas vraiment cohérent entre les deux, mais du coup je comprends pourquoi n'importe qui pouvait supprimer les fichiers sur le dossier partagé dont je parlais au début : ils ont été recopié à l'origine depuis un disque externe en exFAT, qui ne gère pas de permissions. Dans ce cas macOS attribue implicitement les permissions en lecture/écriture pour tout le monde, donc les fichiers ont été recopiés avec ces permissions là sur le NAS. Conclusion : je vais me restreindre à l'utilisation de NFS en lecture seule dorénavant ! EDIT : je rappelle que j'utilise les paramètres NFS suivants côté Syno : "Authentification Sys" et "Mappage de tous les utilisateurs sur admin"; ça fonctionne peut-être différemment avec d'autres paramètres.

Tu as trouvé une solution, depuis ? Je suppose que le script lancé par automator n'est pas interactif, et on peut donc pas entrer le mot de passe. Si on veut automatiser le montage il faut que l'authentification SSH se fasse avec une paire de clefs plutôt qu'avec un mot de passe. Et pour que le montage soit disponible dès le boot, je regarderais du côté de automount plutôt que d'automator.

Oui il faut que je regarde à tête reposée ce qui se passe côté NFS...