CoolRaoul
-
Compteur de contenus
5863 -
Inscription
-
Dernière visite
-
Jours gagnés
57
Messages posté(e)s par CoolRaoul
-
-
il y a 15 minutes, oracle7 a dit :
Si j'étais toi pour éviter à l'avenir de nouveaux blocages d'@IP je mettrais l'@IP du routeur dans la listes des permissions "Autoriser/Bloquer la liste" au niveau Sécurité > Compte.
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!
0 -
Résultat du test (apres avoir réinstallé application)
• Activation (user+pass) à 16:15
• Terminée à 16:21Dernière chance : je vais refaire un essai après redémarrage du téléphone
0 -
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!
il y a 9 minutes, Kramlech a dit :Et tu as vérifié ce que tu as dans la liste des IP bloquées ? (Sécurité, Protection)
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.
0 -
J'ai laissé tourner la connexion drive et ça se termine par ça
Dingue non?
0 -
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)
0 -
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.0 -
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.
0 -
Oh je n'avais pas fait gaffe à ça dans les releases notes 😮
CitationDSM 7.0.1 consumes more system resources, including memory. Make sure your NAS has at least 1 GB of memory before updating.
Après, mon DS213j et ses 512MB semble quand même supporter.
0 -
il y a 45 minutes, Jeff777 a dit :
Ce que je comprends c'est que l'on ne peut plus télécharger l'update1.
Que se passe-t-il pour toi quand tu cliques sir le bouton "download" ?
0 -
il y a 14 minutes, Al1ternet a dit :
J'ai essayé de upgrader mais impossible si quelqu'un aurait une astuce je suis preneur.
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 impossible0 -
Il y a 5 heures, Al1ternet a dit :
J'ai aussi fait l'update j'espère ne pas rencontré des problèmes
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é.
0 -
ah bon? Le minimum ne serait il pas d'avoir au moins un message d'erreur explicite ?ça ne me choque pas effectivement qu'il n'y ait pas de pop-up dans cette dernière.
Sans oublier que ça rend caduque l'option de mise à jour automatique aussi.
0 -
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)Bonsoir,
l'app DS Finder ou L'interface web "mobile"? Si c'est l'interface web c'est possible de forcer (au moins sur iOS) le version "desktop"
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.0 -
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é).Je vais tenter une mise à jour via l'interface Web
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?
0 -
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.Quelqu'un va bien te trouver ça,
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
0 -
Citation- Definition de WATCHED_DIR sans les ${}
La syntaxe "${1:-<valeur_défaut>} permettait de mettre un défaut sauf si spécifié explicitement en $1
Citation- Rajout de l'event "moved_to"En en effet, ça dépend si le fichier est directement copié/généré dans le dossier ou juste déplacé
Citation1) Filtrer les formats de fichiers monitorés (".epub")Après le "do" ajouter:
[[ $1 == *.epub ]] || continue
Citation2) Gérer l'envoi du mail.Quelqu'un va bien te trouver ça,
0 -
il y a 8 minutes, oracle7 a dit :
Il te manquerait pas tout simplement un "/" devant "volume1" dans tes chemins ?
Tout à fait
0 -
A mon avis, le plus light (en termes de ressources en particulier) est de le faire via un script shell.
Le pre-requis est d'installer ce package "inotify-tools":
Ensuite lancer en tache de fond un script basé sur ce modèle :
#!/bin/bash PATH=/bin:/usr/bin:/usr/local/bin WATCHED_DIR=${1:-/var/tmp/watched_dir} # répertoire que j'ai utilisé pour tester # inotifywait --recursive \ --quiet \ --event close_write \ --format "%w%f" \ --monitor $WATCHED_DIR | while read newfile do echo >&2 "received: $newfile" # ici ajouter la commande pour envoyer le fichier "$newfile" par email done
Pour la commande email je pense qu'un autre membre du forum saura proposer une façon de faire.
En ce qui concerne le lancement automatique du script, je préconise, après l'avoir testé à la main, de le faire au boot, via le gestionnaire de taches (task manager) de cette façon :
0 -
apres reboot ca me dit "update available"
Je vais tenterBon ca s'est débloqué, fausse alerte
0 -
Je m'aperçois dans le package center que ce paquet reste bloqué sur "updating..."
Je n'ai pas la moindre idée pour me sortir de cette situation. Si quelqu'un à une idée miracle.
0 -
DSM 7.0-41890
dans Firmwares
il y a 15 minutes, PiwiLAbruti a dit :Le gain de performance est très appréciable sur ce modèle.
Je peux confirmer en connaissance de cause
0 -
il y a 14 minutes, Mic13710 a dit :
je n'autorise pas les accès de l'extérieur aux équipements sensibles. Pour ceux-là, je passe par le serveur VPN : DSM, le routeur, la box, mes bornes Wifi, mes caméras, etc..
Ca doit poser problème pour le renouvellement auto de(s) certifcat(s) let's encrypt non?
0 -
il y a 46 minutes, bliz a dit :
si tu te coonecte en http, toute connexion n'étant pas crypté, récupérer les pseudo et pass pour un hackeur est un jeu d'enfant. Après, avec ça, pas compliquer de rentrer dans le nas et de mette le boxon.
Mais qui a suggéré de se connecter en http? On a simplement dit que laisser le port non chiffré ouvert était sans danger du moment qu'on ne l'utilise pas, rien de plus. (et donc, bien sur, que de ce fait c'est inutile de l'ouvrir à l'extérieur on est d'accord la dessus)
Cela dit, je répète, aucun danger à le laisser ouvert: vu qu'on ne l'utilise pas il n'y aura rien à capturer puisque aucun traffic.
0 -
il y a 8 minutes, bliz a dit :
justement, dans un connexion wifi, cela change tout. L'envoie des peudo et pass sont en clair. Ils peuvent être récupéré, surtout si le wifi est public
Sur le port en clair ça sera les pseudo et pass que le "hacker" utilise lors de ses essais pour tenter de se connecter, quelle importance?
Je suis d'accord que fermer le port non SSL est légitime, mais simplement parce que ça ne sert à rien de le laisser ouvert, pas pour raison de sécurité.
0
Connexion Drive soudain impossible
dans Accès à vos données
Posté(e)
Ce n'est pas une solution applicable pour moi: