CoolRaoul

Et j'attends combien de temps qu'il se passe quelque chose? Note: j'ai lancé cette capture avec ma connexion Drive active en IPV4 (pendant laquelle j'ai fait un transfert de fichier) et je n'ai rien vu passer Et le port 6690 est bien en écoute autant en IPV4 qu'en IPV6 tcp 0 0 0.0.0.0:6690 0.0.0.0:* LISTEN 19730/syncd tcp6 0 0 :::6690 :::* LISTEN 19730/syncd [root@fserv_~]$ ps -fp 19730 UID PID PPID C STIME TTY TIME CMD root 19730 1 0 Jan18 ? 00:27:49 /var/packages/SynologyDrive/target/sbin/syncd

le grep ne capture rien Je l'ai initialement constaté avec le smartphone connecté au WIFi, même LAN sur mon NAS.

Rien qui ne ressemble à ça dans la version Android

C'est bien ça Le nom que j'utilisais pour me connecter était déclaré dans la console d'admin de domaine de mon hébergement sous forme d'enregistrement de type "A" (IPV4) avec l'IP correspondante *et* sous forme d'enregistrement de type "AAA" (IPV6, avec l'IP du NAS lui-même) J'ai créé un enregistrement avec un autre nom (type "monnas-V4.<mondomaine>.com") et, en utilisant ce FQDN dans le formulaire de connexion Drive ce qui force l'utilisation de l'IP V4 la connexion se fait normalement (ne prend pas des plombes)

Oui j'ai compris entre temps, tu voulais dire ne pas utiliser https. Mais entre-temps j'ai pu déterminer que mon problème est lié à IPV6 et pas SSL (et ça reste mystérieux)

Oui: Ce n'est forcément pas un pb d'autorisation puisque ça marche si on patiente (beaucoup) non? ***EDIT*** Suis parvenu à cerner le périmètre du PB C'est bien IPV6 qui déconne (le passage par l'IP V4 "en dur" m'avait mis sur la voie) J'ai ajouté une entrée IPV4 de type "A" sans alias de type "AAAA" dans ma zone DNS et en utilisant celle-là plus de timeout Mais la raison pour laquelle le phénomène n'impacte que Drive et pas les autres applis Syno m'échappe complètement.

Impossible: je suis chez Free Par contre j'ai remplacé le dom de mon NAS par son IP (V4) dans le formulaire de connexion (ce qui revient au même). Pas de changement Il est important de noter que dans tous les cas la connexion finit par aboutir (j'avais mon smartphone laissé sur "connexion en cours" hier et ce matin Drive était connecté) mais le temps d'établissement de session est ridiculement long. Effectivement, en HTTP je suis parvenu à obtenir une connexion quasi est immédiate. Mais étrangement uniquement si j'utilise l'IP et pas le nom. Allez comprendre. (faudra quand même faire d'autres expériences pour valider) En quoi consiste cette opération?

Ce n'est pas une solution applicable pour moi: Docker pas supporté par mon petit NAS. Je cherche une solution simple à mettre en oeuvre, non seulement pour moi (et encore je me débrouille, merci) mais pour d'autres utilisateurs de mon NAS (des membres de la famille). Drive correspond à mon utilisation et dans ce contexte fonctionnait parfaitement jusqu'ici. Je ne cherche pas de fonctionnalités supplémentaires.

Oui j'y penserai dans l'avenir (à noter que je n'ai eu qu'un seul blocage pour le moment lors de mes tests en cours) Mais pour l'instant c'est ce probleme de lenteur extrème qui me préoccupe. Et voilà maintenant un nouveau mystère: La version de Drive qui s'affiuche sur le Play Store est la 2.2.0: Cette que je viens d'installer s'annonce comme la 2.3.0: Et je découvre une 2.5 ici sur le site Synology! https://community.synology.com/enu/forum/1/post/149404 je vous avoue être un peu perdu!

Résultat du test (apres avoir réinstallé application) • Activation (user+pass) à 16:15 • Terminée à 16:21 Dernière chance : je vais refaire un essai après redémarrage du téléphone

Je suis reparti à zero. La connexion a fini par se faire mais ça a pris un temps fou. Et une fois connecté tout est extrêmement lent, carrément inutilisable Et je répète : DS File (meme adresse , meme compte NAS) fonctionne sans aucun problème! C'était l'IP de mon routeur (coté interne). Je l'ai supprimé de la liste des blocages autos. Reste ces lenteurs inexplicables (alors que c'est OK via QuickConnect je rappelle alors que ça devrait être le contraire) Je viens de refaire à nouveau une connexion, entre le moment où je saisis le MdP et celui ou l'interface s'affiche sur le smartphone il ne se passe pas moins de 8mn, chrono en main.

J'ai laissé tourner la connexion drive et ça se termine par ça Dingue non?

De retour à la maison, et la redirection de port n'a pas sauté Et un test externe d'ouverture de port le démontre aussi: Confirmé par un "tcpdump port 6690" en session shell en live sur le NAS (je vois le traffic lors du test de port mais pas du rout lors de la connexion du client Drive)

Je vais vérifier ça dès que je suis de retour chez moi. Reste que ça me semble bizarre que seulement cette redirection soit impactée et pas 5001 par exemple. De plus si c'etait bien ça j'aurais reçu un refus immédiat ("connexion refused" ou similaire) et pas ce truc qui tourne en rond.

Bonjour, M'arrive soudain un truc étrange . Je ne peux plus connecter mon smartphone à mon NAS via Synology Drive en utilisant mon nom de domaine en https (ça tourne en rond sur "connexion en cours"). Ça marche en utilisant quickconnect par contre. Le plus étrange est que ça reste fonctionnel pour les autres applications synology, DS File par exemple. Je ne parviens pas à imaginer une explication à ce comportement.

Oh je n'avais pas fait gaffe à ça dans les releases notes 😮 Après, mon DS213j et ses 512MB semble quand même supporter.

Que se passe-t-il pour toi quand tu cliques sir le bouton "download" ?

Le support m'a donné ce lien pour mon modèle, ds213J : https://www.synology.com/en-global/support/download/DS213j?version=7.0#system Je simplement téléchargé le .pat et lancé upgrade tour simplement. Je ne suis étonné que ce soit impossible

Faite hier pour ma part, manuellement à la demande du support dans le cadre d'un ticket en cours. J'espère ne rien avoir cassé.

ah bon? Le minimum ne serait il pas d'avoir au moins un message d'erreur explicite ? Sans oublier que ça rend caduque l'option de mise à jour automatique aussi.

L'option "DSM Mobile" de DS Finder lance en fait l'interface Web en mode mobile, c'est *strictement* équivalent (suffit de tester pour s'en convaincre) Et dans les deux cas il est en effet également possible de forcer l'interface "desktop" Mais on conviendra que sur smartphone niveau ergonomie cette dernière est pas confortable. D'ailleurs pour faire l'upgrade du paquet je suis finalement passé par mon navigateur PC, quand-même plus pratique.

La dernière fois c'était "Synocli File Tools", Cette fois c'est "Synocli Network Tools" Mise à jour impossible via DS Mobile. Et ce message dans les notifications : Unable to install "/volume2/@tmp/@synopkg/@download/synocli-net/@SYNOPKG_DOWNLOAD_synocli-net". Ce paquet est publié par un éditeur inconnu. ("publié par un éditeur inconnu." . A quoi je serai tenté de répondre : "en effet, et alors?") Je vais tenter une mise à jour via l'interface Web (en espérant qu'ils ne faille pas systématiquement rebooter pour mettre à jour les paquets tiers) Ça a fonctionné. (Il m'a fallu valider un demande de confirmation avec une clause de non responsabilité). Conclusion : il semble qu'il soit désormais impossible de mettre à jour les paquets "communauté" à partir de DSM Mobile. Ne me semble pas que c'était le cas avant. Je me trompe?

Ci joint un script ("my_sendmail") perl (qui nécessite bien entendu l'installation du paquet correspondant) que j'utilise pour envoyer des mails en ligne de commande. Son mode utilisation est en tête du code. my_sendmail Et si tu préfère quelque chose de plus propre, il y a ça (pas testé) : https://github.com/zehm/sendEmail

La syntaxe "${1:-<valeur_défaut>} permettait de mettre un défaut sauf si spécifié explicitement en $1 En en effet, ça dépend si le fichier est directement copié/généré dans le dossier ou juste déplacé Après le "do" ajouter: [[ $1 == *.epub ]] || continue Quelqu'un va bien te trouver ça,

Tout à fait