CoolRaoul

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?

https://www.dealabs.com/bons-plans/synology-ds216ii-serveur-nas-enclosure/370636?comment=6428780 1Go de ram c'est *juste* pour ce type de NAS ? C'est un troll ou bien?

Voilà pourquoi j'ai écrit être d'accord en ce qui concerne la forme. Mais quand on n'est pas débutant ça gonfle un peu de de retrouver avec une réponse semblant s'appuyer sur des mots-clés plutôt que sur le contenu des résultats de tests détaillés fournis (vécu)

OK sur la forme, par contre sur le fond, je ne suis pas loin de penser comme lui: mes dernieres expériences avec le support n'ont été particulièrement positives.

Comme ça:

Ca doit contenir du shell, tout simplement Dans le champ script commencer par "set -x" suivi de la commande "ping ..." On aura alors forcément la trace de l'exécution dans la sortie d'erreur CF ci-dessous:

je ne comprend pas cette phrase as-tu bien utilisé le menu "action" -> "afficher le résultat" du planificateur de tache pour vérifier comment la tache s'est exécutée? https://www.synology.com/fr-fr/knowledgebase/DSM/help/DSM/AdminCenter/system_taskscheduler

Ok, je répond aux deux questions alors: Les deux approches sont possibles. C'est comme on veut. Plus exactement la zone "tache" est destinée à contenir un script shell, on peut se contenter de mettre juste la ligne de commande qui invoque le script externe . Pas forcément: si on l'invoque par "sh /chemin/du/script" ce ne sera pas nécessaire. Sinon, il est aussi possible de se contenter d'enregistrer le NAS chez Synology et activer le heartbeat via le panneau de conf DSM. Pour vérifier son état: https://account.synology.com/fr-fr tu sera prévenu par mail des pertes et reprises de connectivité (tu n'auras pas la précision à la minute pres par contre, à voir si c'est vraiment indispensable)

Et tu veux qu'il se passe quoi quand ça arrive?

Pourquoi parles-tu de Windows 7 , 8 etc ???? Je suis sous windows 10 (pas pro) et je serais surpris que, sur ce point, le fonctionnement soit différent sous home. M'étonnerais pas que tu n'ai pas testé exactement dans le même contexte. Enfin, bref, à part ça, je constate que tu es parvenu à épuiser la patience de @Lucien77 @Mic13710 (qui pourtant en ont vu d'autres!) et les autres participants à ce fil. Mon tour est venu de lâcher prise. Bonne continuation.

je n'ai jamais dis le contraire. J'ai pris le temp de tester (ce que tu aurais pu également faire de ton côté avant d"émettre des hypothèses): en fait ça n'a aucun rapport avec le fait d'être ou pas sur un compte admin. C'est uniquement quand on se connecte, dans le contexte de sa session Windows, au NAS avec une compte (username) *différent* du celui de la session windows qu'un mapping (net use) est créé (peut-être également si le mot de passe est différent, j'ai pas testé jusque là) Donc dans ton cas, puisque apparement c'est de cette façon que tu pratiques (username NAS <> username Windows) la solution donnée par @Fenrir me semble la plus rapide. Suffit juste d'ajouter juste un "/yes" à la commande net use pour se passer de confirmation: net use * /delete /yes

Ca à toujours fonctionné comme ça pour moi sur tous les Windows que j'utilise, que ce soit à domicile ou au travail Je suis connecté à mon Windows sur un compte simple utilisateur avec les même identifiants (user/pass) que mon compte DSM et je n'utilise pas le mappage de lecteur (n'en ai jamais eu le besoin), uniquement les chemins UNC (format "\\nom\..."). Me semble que c'est une pratique courante. Les compte admin Windows et du NAS je les réserve pour des actions nécessitant des privilèges, ponctuellement donc. Si on relit ton premier message, il n'était pas question de serveur distant que je sache je cite: Ce qui rend encore plus inexplicable d'avoir dit un peu plus haut que tu ne connaissais pas cette méthode

Bien entendu: je le fais régulièrement et ça marche aussi bien avec juste le nom du serveur ou avec un chemin complet.

Comme pour toute connexon à un dossier réseau partagé sous Windows Et il existe plusieurs méthodes: démarrer -> exécuter -> "\\<monas>\<partage>\<chemin>" Dans la branche "réseau" de l'explorateur, en dépliant l'entrée correspondant au NAS Ou directement en tapant dans le champ adresse de l'explorateur:

Merci de me prendre pour un newbie ... J'ai écrit "dans l'explorateur" et pas "dans le navigateur".

Je ne pense pas que cette solution s'applique à tous les cas. Je suis actuellement connecté dans une session windows 10, via l'explorateur j'ai bien accès à mon nas en utilisant sur mon compte DSM et malgré ça, voici ce que "net use" dans une boite de commande me répond: $> net use Les nouvelles connexions seront mémorisées. La liste est vide.

Normalement faudrait ouvrir un ticket de support chez Syno. Mais mes deux dernières expériences m'ont franchement découragé. Je laisse ça aux plus patients que moi (d'autant plus que, la commande n'étant pas documenté et donc pas officiellement supportée, ça leur serait encore plus facile de botter en touche)