Deadbone

Bonjour, De temps en temps je fais un backup de quelques répertoires placé sur mon NAS (DS713+ en 5.1 aujourd'hui donc) avec la commande rsync pour placer les fichiers sur un disque dur relié à mon MacBook Pro (Le Nas est un peu difficile d'accès pour brancher un DD supplémentaire) En dsm 5.0, tout fonctionnait correctement... depuis ce matin (cela fait quelques temps que je n'avais pas fait de backup) je me fais jeter par rsync : permission denied. Je n'ai pas changé de commande, mon user sur le Nas a les droits d'admin (d'ailleurs j'ai désactivé le compte admin, mis les droits qui vont bien dans sudoers ...) J'ai aussi remarqué quelque chose d'étrange : dans le widget "Utilisateurs connectés" ce n'est pas mon user qui apparait en ssh, mais "admin" (alors que ce compte est désactivé, je l'ai même réactivé puis désactivé pour être certain) Dans un terminal, si je lance un who, ou un whoami, c'est bien le user que j'utilise qui apparait... J'ai l'impression que le fichier /etc/sshd_config a evolué récemment mais j'ai même plutôt l'impression que cela date du dernier update de la version 5.0 (le passage au 5.1 s'est fait très vite) Si quelqu'un a une idée, je suis preneur... Merci d'avance

Bonsoir, Ces mp3 sont bien dans le répertoire partagé /volume1/music ? L'utilisateur est-il autorisé à utiliser audio station ? (panneau de configuration->Utilisateur puis double clic sur utilisateur concerné, onglet Applications, Audio Station coché) D.

Bonjour, Oui, cela doit être possible en parsant les logs et en filtrant sur la date du jour. Après, est ce que ça existe clef en main, je ne sais pas... mais c'est une tâche que j'ai prévu de faire pour mes propres besoins dès que j'aurai le temps. Sinon, tu peux utiliser le planificateur de tache qui te générera un rapport sur ton syno et qui t'enverra un mail avec le lien pointant vers le rapport... ce n'est pas 100 % ce que tu veux, mais c'est ce qui s'approche le plus en natif.

Merci CoolRaoul, /bin/su -s /bin/ash -c "<chemin_complet_du_script>" - <compte_cible> me permet de lancer mes scripts ! je ne vois pas comment faire pour mettre ce thread en "résolu" …

Merci pour ces précisions... je me rends compte que je suis un peu léger sur certaines commandes / notions de droits ... Je teste ce soir Et merci pour avoir passé du temps sur cette problématique

En revanche, dans mon script, /usr/bin/id >> $FICHIER echo "*******" >> $FICHIER id >> $FICHIER donne la même chose quand je "force" l'exécution du script via le DSM loggé avec le user en question et le script prévu pour être lancé avec cet utilisateur ... sortie : uid=0(root) gid=0(root) groups=100(users),101(administrators) ******* uid=0(root) gid=0(root) groups=100(users),101(administrators) ​Je vais donc tester la spécification du chemin de la clef dès que je pourrai (le syno n'est pas très waf )

effectivement, l'appel à "id" directement dans le champ du planificateur donne bien une ligne comme la tienne : uid=0(root) gid=0(root) euid=1026(clampin2) egid=100(users) groups=100(users),101(administrators) (mon user a les droits admin)

de retour voici la sortie de la commande id que j'avais mise dans mon script : uid=0(root) gid=0(root) groups=100(users),101(administrators) J'ai ajouté le path du home du USER desiré, mais pas de changement de comportement... je vais donc essayé d'indiquer le chemin de la clef

Merci pour ces pistes, je testerai (plutôt ta 2eme préconisation) ceci bientôt et ferai un retour ici.

Personnellement, le time machine est enfin opérationnel depuis quelques jours : j'ai créé un user sur le même modèle, un répertoire du même nom que le tutoriel synology, lancer le serveur FTP (alors que d'après moi, Time machine utilise le protocole afp, sauf erreur ) qui était inactif et tout fonctionne.

Bonjour, Je suis tombé sur un problème assez gênant sur un DS713 avec le dernier DSM en date, ipkg fonctionnel. Je cherche à programmer une tâche (script bash établissant une connexion ssh vers serveur distant via echange de clef, pour effectuer certaines taches sur ce serveur distant ) via le planificateur en précisant bien le USER concerné (qui est dans le groupe administrateur) . Je me suis rendu compte que ma connexion était refusée suite à un problème de clef (alors que si je teste le contenu en ssh via le compte USER concerné depuis le SYNO, tout fonctionne parfaitement) ... J'ai ajouté la commande "id" dans mon script pour vérifier quel était le USER qui était utilisé pour le lancement de la tâche... et au lieu de voir mon USER, je vois la mention "root" J'ai édité le crontab, et effectivement, ce n'était pas le USER spécifié dans le planificateur mais le root. J'ai remplacé "root" par le USER en question, stoppé et relancé le cron avec les commandes dédiées... mais le problème subsiste. Donc, dans mon cas, spécifier un USER spécifique dans le planificateur ou dans le crontab ne sert à rien : le root prend toujours la main. Une solution rapide serait de créer des clefs SSH pour le root et d'apairer mon serveur distant, mais cela me plait moins que de comprendre l'origine du problème, et de le corriger Si quelqu'un a une solution, une piste, je suis preneur

Bonjour, Même souci par intermittence sur un DS713 récemment acquis et dernière version de DSM. Pas d'autobloquage activé. Le message "vous n'êtes pas autorisé à utiliser ce service" apparait quand je suis en local (même réseau) et pas d'accès depuis l'extérieur car je n'autorise que l'accès local (pas de forwarding de port vers le NAS) Si quelqu'un a une idée …

up itoo svp