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

J'avais essayé de faire une redirection 8001-->8001, et le client mobile ne trouvait pas tout seul la connexion... D'après mes différents tests il semble bien qu'il cherche le 5001 uniquement, et s'il ne le trouve pas il faut lui indiquer lequel utiliser. Je confirme pour le client de bureau qu'on peut lui préciser un autre port (et qu'il en tient compte) Oui, ok

Ah ça c'est fort possible ! Oui pour tout. Et en effet monnas.mondomaine.fr:18001 fonctionne dans ces conditions. Mais mon dernier questionnement c'était "dans quelles conditions ça peut marcher sans préciser aucun port" ? Pour moi ça ne marchait pas, alors que d'autres rapportent qu'ils n'ont besoin de préciser aucun port dans le client mobile. Mais ça y est j'ai trouvé : pour ça il faut (et même il suffit) que le port 5001 (celui par défaut de l'interface d'administration https de DSM) soit redirigé vers le NAS. Bon, c'était juste par besoin de comprendre... Ben en fait pour le client mobile il n'y a même pas besoin de le rediriger du tout, apparemment... Ca marche aussi bien sans. Par contre il le faut pour le client de bureau. Oui, si le port 6690 est redirigé tel quel. Si c'est une redirection par exemple 16690-->6690, il faut que je mette monnas.mondomaine.fr:16690 pour que ça marche. Il y a quand même une différence fondamentale entre le le client mobile et le client de bureau sur le(s) port(s) utilisé(s).

Même si maintenant ça marche, il reste une question : pourquoi avec le client mobile suis-je obligé de préciser le port depuis l'extérieur, même quand dans la règle NAT je redirige 6690 vers 6690 (donc sans changer le numéro) ? D'après @.Shad. ça devrait marcher sans préciser le port, et quelqu'un d'autre sur un autre forum me certifie que chez lui ça marche sans préciser, en ne redirigeant aucun autre port que le 6690, et sans même avoir défini des ports personnalisés pour l'interface web de Drive...

Bon, ça se démoule, mais il y a de quoi s'y perdre : Sur le NAS j'avais assigné dans Drive Server le port 8000 à l'accès http, et 8001 à l'accès https. Sur la box je faisais suivre le port 18001 vers le port 8001 du NAS et le port 16690 vers le port 6690 du NAS (vieille habitude de changer les numéros qui ne sert sans doute à rien... surtout pour les ports qui ne sont pas en dur 😄 ). Sur mon Mac, j'avais paramètré le client DS Drive avec <Server adress: monnas.mondomaine.fr:16690> et ça bien marchait comme ça (et ça marche toujours !). Je viens par ailleurs de vérifier, si je ne précise pas le port il cherche par défaut le port 6690 (et ça ne marche que si je fais suivre ce port sur la box). Donc naturellement j'ai initialement essayé de paramétrer le client Android (et ensuite iOS) de la même façon : c'est là qu'est le problème ! Il faut le paramétrer avec le port de l'interface : <Adresse : monnas.mondomaine.fr:18001>, et là ça marche ! Même pas besoin d'ouvrir un port sur la box pour le port 6690, en fait (j'ai testé en supprimant toute redirection pour ce port et ça marche tout aussi bien). Par contre mettre le port est obligatoire (ce qui parait logique, comment pourrait-il deviner sinon...). Donc problème initial résolu (c'était l'accès en https depuis l'extérieur). Mais quelle idée ont-ils eu de faire différemment entre le client desktop et le client mobile ??? Et en local sans https, ça ne marchait pas non plus depuis iOS et Android, mais pour la même raison : je mettais le port 6690 au lieu de 8000... Avec 8000 ça marche, et sans préciser le port ça marche aussi (comment devine-t-il d'ailleurs, vu que ce n'est pas un port codé en dur dans DSM ?)

Non. J'ai un abo internet avec une IP fixe, et un nom de domaine (monnas.mondomain.fr) qui pointe sur cette IP fixe. J'ai mis une règle NAT sur la box pour faire suivre le port utilisé par Drive Server. La box gère le loopback donc en principe que je sois sur mon réseau local ou pas je peux établir la connexion avec l'adresse publique. Ca marche très bien depuis mon Mac, je peux me connecter à Drive aussi bien avec l'adresse publique+https qu'avec l'IP locale (sans https). J'ajoute quelques éléments, qui renforcent mon incompréhension : Depuis Android, comme dit précédemment, le client trouve le NAS par l'adresse publique mais râle que le certificat n'est pas bon. Depuis Android, le client ne trouve pas du tout le NAS par l'IP locale ! Depuis iOS sur un iPhone, le client ne trouve pas du tout le NAS, que ce soit par l'adresse publique ou locale (capture ci-dessous) !

Oui, tous les services (dont "Synology Drive Server") utilisent le certificat LE (qui ne pose aucun problème quand j'accède à l'interface web en https par Firefox).

Apparemment ça ne change rien...

Oui aux deux questions (d'ailleurs le client trouve bien le NAS, c'est juste que le certificat ne lui plaît pas). Dans ce cas je ne peux pas : tant que la connexion n'a pas été établie, le client n'offre aucun menu autre que l'écran de connexion... Je vais tenter l'installation du certificat sur Android.

Bonjour, ...je n'ai rien chargé sur Android. Nulle part dans les doc Synology je ne vois qu'il faudrait faire ça : https://www.synology.com/fr-fr/knowledgebase/Mobile/help/Drive Cela dit je ne comprends pas non plus leurs instructions, par exemple : "Activez l'option Vérifier le certificat dans > Paramètres de connexion pour valider le certificat SSL installé sur votre Synology NAS."... Ce n'est pas clair du tout si c'est sur le NAS ou sur Android qu'il faut faire cette manip (et je ne trouve ce menu nulle part)

Bonjour, Je veux installer Synology Drive sur un appareil Android, et ça bloque au moment de la configuration de la connexion au NAS. Il me dit que le certificat SSL n'est pas fiable. J'ai en fait ce même message quand je configure la connexion du client sur un Mac, mais le client Mac permet quand même de passer outre, alors que sur le client Android je n'ai pas d'autre choix de faire "OK" et il revient à l'écran de config. Comment faire pour valider quand même ?? Au passage je ne vois pas bien en quoi le certificat ne serait pas fiable, c'est le certificat de "Let's Encrypt" fourni par l'interface du Syno (et je n'ai aucun avertissement de certificat quand je me connecte à l'interface du Syno en https depuis un navigateur)

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 ?