CoolRaoul

Ah , pas bon ça. Je verrai à tète reposée si y a moyen de tracer ce qui ce passe. Merci en tout cas

Oui c'est ce que je prévois de faire plus tard, mais c'est quand même un peu dommage d'avoir une version packagée au format DSM qui ne fonctionne pas.

Ah ok, et de toutes façon la tentative de cohabitation se solde par un: La cause de l'erreur n'est donc pas la Je vais tenter de réinitialiser mon MariaDB 5, de toutes façon je n'avais pas d'appli qui l'utilise en ce moment

Je viens de m'apercevoir que C'est Mariadb 5 et pas 10 qui est installé sur mon NAS Je vais installer le second (je me demande comment se passe la cohabitation..)

Le paquet Synocommunity. C'est pourquoi je poste dans cette section ("La Communauté" -> "Paquets fournis par SynoCommunity.com")

Je ne parviens pas à installer Selfoss, ça plante avec l'erreur suivante: et pourtant je n'ai aucun doute sur le mot de passe root MariadDB je peux me connecter sur mon phpmyadmin sans problème Si quelqu'un à une piste

Je tentais l'installation connecté en remote proxy, il y a parfois des anomalies d'upload dans ce contexte

Boite allemande à l'origine, et son staff semble encore composé essentiellement d'allemands https://www.teamviewer.com/en/company/leadership/

https://community.teamviewer.com/t5/TeamViewer-IoT-Labs/IoT-WebControl-solution-and-Synology-NAS-boxes/td-p/33052 NB: ne s'installe pas sur mon DS213j par contre:

Fervent utilisateur de Keepass, J'y ai jeté un oeil également, mais là aussi le projet semble un peu à l'abandon: la dernière livraison est datée de plus de deux ans et demi. Je viens de le tester et je rencontre par exemple aussi l'anomalie des menus en doubles signalée dans la buglist, pas rassurant. De son coté Authy m'a l'air pas trop mal fichu.

merci, je vais tester La moindre des choses pour une appli de ce genre

Je connaissais pas et j'ai voulu tester pour éventuellement remplacer l'appli de Google Par contre j'ai bien l'impression que le produit à été abandonné: le site sur lequel il était hébergé à été fermé le mail de support donné dans la fiche google est celui de la mailing list du projet et cette dernière semble ne plus avoir la moindre activité Résultat, en cas de problème (incompatibilité avec nouvelle version Android par exemple) on se retrouve à poil non?

Je parlais du support *des* clés USB en général, pas d'une en particulier. Et je tenais surtout à souligner que cette annonce laisse entendre que la liste des compatibles à aucune chance d'évoluer dans le bon sens à l'avenir.

Attention sur la pérennité du support des clés USB (en dehors de celles de stockage) , je suis tombé sur ce post du forum récemment qui m'a un peu refroidi. La source est ici: "Starting from DSM 6.2, the USB device drivers, including printers, cloud printers, DAC/speakers, Wi-Fi dongles, DTV dongles, LTE dongles, and Bluetooth dongles, will no longer be updated." Autrement dit, on court peut-être le risque qu'une clé WIFI actuellement supportée ne le soit plus à l'avenir.

Voila qui est dommage pour l'enregistrement direct du flux antenne TNT via VideoStation: ça permettait à peu de frais de passer outre les restrictions imposées par certains diffuseurs sur l'enregistrement du flux ADSL (et même TNT sur les box!) Sans oublier la possibilité de faire des enregistrement HD sans monopoliser sa bande passante internet pour ceux qui ont des débits restreints

Si on veux être plus rigoureux c'est pas "n'importe quel partage" et le "on" ne signifie pas n'importe quel compte client non plus: ne s'applique qu'aux partages pour lesquels on a explicitement spécifié des entrées d'autorisation NFS. Uniquement à partir de machines client NFS qui "matchent" une des entrées autorisations définies ci dessus. et pour ces dernières, seulement à partir des comptes faisant partie d'un groupe dont la valeur de GID est 101 (administrateurs sur le NAS). important: c'est le comportement normal de NFS pour les partages dont la sécurité est de type "sys". Dans ce cas, l'UID du user source et la liste des GIDS de ses groupe sont pris en compte tels quels sur le NAS pour autoriser ou nom l'accès demandé à la ressource et chacun des fichiers/répertoires qu'elle contient (ce mapping serait configurable via le mécanisme idmapd mais il semble impossible de l'activer complètement sous DSM) Techniquement il est possible de désactiver le droit d'accès à un partage au groupe "administrateurs" (droit attribué par défaut). L'inconvénient est que ça implique sa non visibilité dans filestation pour les compte administrateurs ("admin" y compris) . Ca complique la gestion des droits du partage. Contournement: créer un groupe spécifiquement destiné à cet usage (administration du stockage) dont le compte "admin" est membre (éventuellement unique). Donner l’accès R/W aux partages à ce groupe à la place du groupe "administrateurs". D'après ce que j'ai lu, ceci ne s'applique plus dans le cas ou on est capable de choisir l'authentification "Kerberos" pour le partage NFS, car dans ce cas on devient capable d'ajuster les mappings UID et GID.

Trouvé! (par itérations): c'est l'appartenance au groupe "101" ("input" sur le pi, "administrators" sur le NAS) qui permet l'accès. (Les droits que j'avais donné au dossier du dossier était ouvert aux administrateurs en plus du compte isolé) Faudrait que je trouve un moyen de maîtriser plus finement le mappage des groupes sur NFS.

C'est bien le cas. La version du protocole est V4 des deux coté. Sinon j'ai un peu avancé dans mes tests. Créé un compte sur le PI avec même user et UID qu'un compte existant sur le NAS, ce dernier n'a pas accès au dossier partagé (ce qui est normal, j'ai limité les droits du répertoire à un autre compte unique) Crée un autre compte sur le PI avec user et UID inexistants sur le NAS: pas d'accès non plus Autre compte ("pi2") créé sur le PI avec même uid et même gid que "pi": toujours pas d'accès Qu'est-ce qui peut bien faire que le compte "pi" du PI soit capable d'outrepasser les droits par NFS? Via ses groupes? pi@rasp.local> id uid=1000(pi) gid=1000(pi) groups=1000(pi),4(adm),20(dialout),24(cdrom),27(sudo),29(audio),44(video),46(plugdev),60(games),100(users),101(input),108(netdev),997(gpio),998(i2c),999(spi)

Non: le compte "pi" c'est le compte par défault de la distrib raspbian sur le raspberry. Pour celui-ci j'ai l'impression que les partages du NAS accédés en NFS deviennent open bar alors que ce compte n'a pas d"équivalent sous DSM ayant le même UID. Je n'ai pas créé de compte "pi" sur le NAS. **EDIT** Désolé si je ne suis pas clair, je reformule: Dans une session shell tournant sur le PI avec le compte "pi" je peux allègrement créer/modifier/effacer des fichier sur le NAS par le montage NFS dans un dossier dont les droits ne devrait pas me le permettre.

Salut, un pote m'a fait cadeau d'un raspberry et je fais un peu joujou avec. J'ai exporté en NFS un des partages du Syno. Dans ce dossier partagé je crée un sous-dossier limité (via les ACLs) à mon compte utilisateur DSM. Je vérifie qu'un autre compte DSM ne peut pas accéder à ce dernier (connecté root en ligne de commande, su - <userlambda> puis touch <chemin du dossier> me donne bien "permission denied". Et pourtant, à partir du raspberry, en étant connecté sur ce dernier au compte par défaut, "pi" (uid 1000) je peux accéder à ce dossier monté NFS et même y créer fichiers et sous-dossiers! Par quelle magie le compte "pi" du raspberry dispose de plus de privileges qu'un compte local DSM?

Fait ainsi, pour que ça fonctionne bien, ça implique de rendre plus ou moins public (au moins en lecture) au dossier $HOME de l'utilisateur "username", non? Me plait moyen ça ...

Est-ce censé fonctionner uniquement avec le dossier "Photo" (celui de photo station) ou n'importe quel dossier contenant des photos? J'ai fait le test de mon coté (je suis dans la 2ème configuration): le dossier ajouté apparaît bien dans "Les dossiers de l'équipe" dans Drive mais aucune de ses photos n'est visible dans Moments.

En effet, contrairement à ce que j'ai initialement pensé, le problème ne se manifeste pas avec n'importe quelles application source (j'ai pu vérifier également qu'une photo partagée a partir de Google photos ne provoque pas cette anomalie). Je l'ai constaté par contreà partir d'un PDF attaché à un email et c'est systématique en partageant un fichier de type quelconque à partir de Google Drive vers DSfile

J'ai ouvert il ya quelques jours un ticket de support pour un problème DSfile que j'ai également signalé ici: https://forum.synology.com/enu/viewtopic.php?f=215&t=137408 Pour être certain que l'anomalie était pas spécifique à ma configuration j'ai pris le temps de faire le test en activant un serveur de demo en ligne: https://www.synology.com/en-global/dsm/live_demo et j'ai pu constater qu'on pouvait y reproduire l'anomalie à volonté. Aujourd’hui je reçois un premier retour et, comme je m'y attendais un peu, la première réponse est : "we need access to your NAS" Pour quelle raison le support Syno a-t-il besoin de se connecter à *mon* NAS dans le cas d'un dysfonctionnement d'une appli Android (DSfile) reproductible sur n'importe quel exemplaire?

Je constate dans le flux "contenu non lu" en mode condensé qu'à la place les dates des messages est affiché le format type "printf" ("%d") Problème également constaté sur d'autre forums sous Invision. L'anomalie a-t-elle été remontée?