Classement

Toutes mes excuses, mes premières recherches n'avaient rien données alors qu'en faite le problème avait déjà été évoqué. Pour ce qui rencontrerait ce problème, il faut utiliser ce post pour résoudre le problème : Je l'ai appliqué, ça marche très bien.

OK. J'ai sauvegardé toutes les données, et la config. Je vais rebooter parce que là ça fait plus de 3j que c'est comme ça, je pense quand même qu'il y a un truc qui va pas ... En revanche, le reboot ça va être arrachage de la prise électrique, le NAS refuse de rebooter ou de s’arrêter.

Bonjour, Est-ce que Syno trouve ton nas dans http://find.synology.com/ ? As-tu essayé de monter ton nas sur ton ordinateur avec le programme Synology Assistant ?

Bonjour, Une nouvelle application (ou service) est apparue depuis la mise à jour 6.0.2, dans l'onglet 'applications' des paramètres des utilisateurs ou des groupes. Et j'ai commis la bêtise de faire 'REFUSER' pour cette application au groupe 'users', ... comme mon compte administrateur dépend aussi du groupe 'users' et bien je suis tombé dans l'impossibilité de me connecter au 'bureau' de DSM via le navigateur web. C'est ballot, je sais ! Je m'en suis bien mordu les doigts, parce que c'est vraiment bête ;-( . Il me restait plus que l'accès en SSH, oui mais comment faire ? je suis novice en ligne de commande linux ... J'ai trouvé un post qui correspondait à mon problème (un grand merci à Jinie): https://forum.synology.com/enu/viewtopic.php?t=122069 Moyennant quelques adaptations, j'ai pu retrouver l'accès au 'bureau du DSM'. Alors, si cela peut servir à d'autres, je mets les informations qui m'ont permis de résoudre mon PB... Les autorisations sur les applications 'SYNO' sont inscrites dans un fichier de base de données 'synoappprivilege.db' dans le répertoire /etc/. La gestion de ce fichier s'effectue à l'aide de "sqlite3". Il faut d'abord savoir sur quel compte ou quel groupe, on a fait 'refuser', pour ma part c'était le groupe 'users'. En visualisant (par la commande 'vi') le fichier /etc/group j'ai noté que l'identifiant du groupe 'users était 100 (users:x:100: => ID=100). En se loggant en SSH, il faut se déplacer dans /etc/, puis ouvrir le fichier avec sqlite3 en administrateur: sudo sqlite3 synoappprivilege.db (le mot de passe administrateur est alors redemandé) On obtient alors le prompt de sqlite3 ( sqlite> ). Avec la commande: sqlite> SELECT * FROM AppPrivRule WHERE ID=100; j'ai obtenu les informations suivantes: 1|100|SYNO.Desktop|||0.0.0.0|0000:0000:0000:0000:0000:FFFF:0000:0000 l'IP 0.0.0.0 et les paramètres 0000:0000:0000:0000:0000:FFFF:0000:0000 sont les zones de DENY (DenyIP et DenyIPStd), il faut les ramener dans la zone 'Allow'. Pour faire cela, j'ai entré la commande: sqlite> UPDATE AppPrivRule SET AllowIP='0.0.0.0',AlowIPStd='0000:0000:0000:0000:0000:FFFF:0000:0000',DenyIP='',DenyIPStd='' WHERE ID=100; Et en refaisant: sqlite> SELECT * FROM AppPrivRule WHERE ID=100; J'ai obtenu: 1|100|SYNO.Desktop|0.0.0.0|0000:0000:0000:0000:0000:FFFF:0000:0000|| Le groupe 'users' (ID=100) est maintenant autorisé à accèder au bureau du DSM. (pour quitter sqlite3, faire sqlite>.exit) Une question me tracasse encore, pourquoi un compte administrateur dépend à la fois du groupe 'administrators' et du groupe 'users' ?? Est-ce normal ? ou bien ai-je loupé quelque chose ? TT