This site uses cookies! Learn More

Ce site utilise des cookies !

En continuant à utiliser ce site, vous vous engagez à nous permettre de stocker des cookies sur votre ordinateur.

 

Si nous utilisons des cookies et retenons des données anonymes, c’est pour nous aider à mieux gérer notre mesure d’audience, aider nos partenaires commerciaux à nous rémunérer et nos partenaires publicitaires à proposer des annonces qui vous correspondent.

 

Grâce à ces cookies, le forum est en mesure de savoir qui écrit un message et utile pour le système d'authentification.

 

En cliquant sur « J'accepte », vous acceptez l'utilisation par NAS-Forum de cookies publicitaires et de mesure d'audience fine.

PierU

Membres
  • Compteur de contenus

    37
  • Inscription

  • Dernière visite

À propos de PierU

  • Rang
    Initié

Visiteurs récents du profil

Le bloc de visiteurs récents est désactivé et il n’est pas visible pour les autres utilisateurs.

  1. Oui enfin, il y a quand même des comportements incohérents dans cette histoire. 1) si on crée un dossier directement sur le dossier partagé ce sont les permissions DSM du dossier partagé qui sont appliquées, alors que si on copie un dossier ce sont les permissions unix d'origine. 2) avec SMB/AFP ce sont dans tous les cas les permissions DSM du dossier partagé qui sont appliquées et seulement elles : mais ce n'est pas le comportement obligé de SMB/AFP, qui normalement tiennent compte aussi des permissions locales. C'est le choix de Synology de faire fonctionner SMB/AFP de cette façon, et ils auraient pu l'appliquer aussi à NFS. L'impression que ça me donne c'est que l'intégration de NFS à DSM n'est pas aussi complète que celle de SMB/AFP (en tous cas avec les options utilisées ici)
  2. Bien, j'ai regardé : Sur le montage NFS du dossier partagé, depuis le Mac : dans le Finder je crée un nouveau sous-dossier, et je regarde ensuite ses permissions dans File Station : ce sont les "bonnes", telles que définies pour le dossier partagé dans DSM toujours dans le Finder je copie des dossiers/fichiers du Mac vers le dossier partagé : dans ce cas, leurs permissions sont les permissions unix que ces fichiers avaient sur le Mac, sans aucun lien avec les permissions du dossier partagé ! Déjà le comportement n'est pas vraiment cohérent entre les deux, mais du coup je comprends pourquoi n'importe qui pouvait supprimer les fichiers sur le dossier partagé dont je parlais au début : ils ont été recopié à l'origine depuis un disque externe en exFAT, qui ne gère pas de permissions. Dans ce cas macOS attribue implicitement les permissions en lecture/écriture pour tout le monde, donc les fichiers ont été recopiés avec ces permissions là sur le NAS. Conclusion : je vais me restreindre à l'utilisation de NFS en lecture seule dorénavant ! EDIT : je rappelle que j'utilise les paramètres NFS suivants côté Syno : "Authentification Sys" et "Mappage de tous les utilisateurs sur admin"; ça fonctionne peut-être différemment avec d'autres paramètres.
  3. Tu as trouvé une solution, depuis ? Je suppose que le script lancé par automator n'est pas interactif, et on peut donc pas entrer le mot de passe. Si on veut automatiser le montage il faut que l'authentification SSH se fasse avec une paire de clefs plutôt qu'avec un mot de passe. Et pour que le montage soit disponible dès le boot, je regarderais du côté de automount plutôt que d'automator.
  4. Oui il faut que je regarde à tête reposée ce qui se passe côté NFS...
  5. Je progresse... au moins dans la correction problème à défaut de comprendre comment il est arrivé. Dans les propriétés du dossier partagé (celles obtenues dans FileStation, pas dans le panneau de config), les permissions du dossier racine sont conformes à ce que j'attends : https://i.imgur.com/1dxHwj5.png (et pour répondre à Daffy, dans les propriétés du dossier partagé dans le panneau de config, l'action "Covertir en Windows ACL" est grisée pour tous les dossiers). Par contre les permissions des sous-dossiers et des fichiers pas du tout ! Exemple sur un des sous-dossiers : https://i.imgur.com/yvRdpaa.png ... il y a un "everyone" qui apparait, avec des permissions en écriture ! J'ai l'impression que ce sont les permissions unix qui ont refait surface à la place des permissions DSM. Du coup je suis remonté dans les propriétés de la racine, onglet permissions, j'ai coché "Appliquer à ce dossier, ces sous-dossiers, et ces fichiers" et fait OK... Et là tout semble rentrer dans l'ordre sur les sous-dossiers : https://i.imgur.com/QfJLuUF.png... et les utilisateurs du groupe MeMs ne peuvent en effet plus supprimer de fichier, OUF ! C'est ce que tu as écrit là qui m'a mis la puce à l'oreille sur les droits explicites ou hérités par les sous-dossiers (je me souvenais avoir déjà vu ça dans FileStation). Bon, ça n'explique pas pourquoi les droits n'étaient plus les bons, mais c'est au moins rentré dans l'ordre pour l'instant.
  6. Ben oui... normalement. Et le problème est que justement ils peuvent. Oui, c'est un dossier partagé que j'ai créé : https://i.imgur.com/rZRdPHr.png Ses permissions de groupe (seul le groupe admins a les permissions d'écriture) : https://i.imgur.com/zOH16RO.pn Ses permissions d'utilisateurs (avec un des utilisateurs concernés entouré en rouge) : https://i.imgur.com/f0N7Ix6.png C'est bien le cas : https://i.imgur.com/jvWLTzN.png https://i.imgur.com/Hxl0sxK.png Tu veux dire retirer ces utilisateurs du groupe "users" ? Mais ce groupe n'a aucune permission définie sur le dossier partagé en question, donc ça ne devrait rien changer (non ?)
  7. Disons que out of the box (sans aucun effort d'optimisation) j'avais les perfs suivantes en lecture : SMB=25Mo/s, AFP=50Mo/s, NFS=90Mo/s. En désactivant la "signature des paquets" côté Mac (je suppose que concrètement ça veut dire le chiffrement) j'atteins 50Mo/s en SMB aussi. Je n'ai pas cherché vraiment plus loin. Oui je sais que ce n'est pas franchement satisfaisant ! Si encore j'étais le seul utilisateur du Mac ça irait, mais là c'est moyen on est d'accord. 1) oui 2) oui. En lecture/écriture le groupe admin (et personne d'autre), et en lecture seule (en principe) entre autre le groupe "MeMs" qui me pose problème actuellement. 3) Non. En NFS il n'y a concrètement que moi qui me connecte à ce partage, depuis le Mac, pour y déposer des fichiers. Les utilisateurs du groupe MeMs se connectent en pratique par File Station (avec leurs ident/mdp). 4) Non. Le problème est que les utilisateurs du groupe MeMs peuvent en pratique faire tout ce qu'ils veulent (supprimer des fichiers, en créer, etc...), alors que dans l'interface DSM ils n'ont en principe que les droits en lecture. Le problème est le même s'ils se connectent par SMB en fait.
  8. Euh... Je n'ai pas compris grand-chose 😐. Je (re)précise néanmoins que l'export NFS se fait avec l'option "mappage de tous les utilisateurs sur admin" sur le Syno : du coup les permissions des utilisateurs déclarés sur le Mac n'ont (en principe) aucune importance/influence... Une des raisons c'est que le débit atteint avec le partage NFS est de 75Mo/s (écriture) / 90Mo/s (lecture), contre 50Mo/s avec SMB ou AFP. Une autre raison est que le montage NFS n'est pas détecté comme un disque réseau mais comme des données locales par un utilitaire que j'utilise, et ça m'arrange.
  9. Bonjour, Je ne savais pas trop où poser cette discussion, qui n'est pas spécifique aux Synology. S'il y a un meilleur endroit vous pouvez la déplacer. Il y a quelque temps j'ai découvert cet article (et d'autres sur le même sujet) qui semble assez connu parmi les "spécialistes" : https://www.zdnet.com/article/why-raid-6-stops-working-in-2019/ C'est à la fois intéressant et inquiétant 🙂 , mais j'ai l'impression qu'il est basé sur une interprétation excessivement pessimiste du taux d'erreurs irrécupérables de lecture (URE rate). Le taux couramment retenu est de 1 URE tous les 10^14... mais 10^14 quoi ? L'article interprète " tous les 10^14 bits lus", ce qui correspond à 12,5To : du coup avec les disques actuels le risque d'URE parait en effet très significatif... Mais l'unité élémentaire de lecture dans un disque n'est pas le bit, c'est le secteur (512 octets, 4096 bits) : donc personnellement j'interprète ça plutôt "tous les 10^14 secteurs lus", ce qui change tout car ça fait 1 URE non pas tous les 12,5To lus mais tous les 50Po lus. Evidemment, si on se met à lire aléatoirement des bits individuels n'importe où sur le disque on va retomber sur les 12,5To puisque pour chaque bit il faut lire un secteur entier. Mais la réalité c'est qu'on a besoin la plupart du temps de toute l'information d'un secteur (à moins de ne manipuler que des ribambelles de petits fichiers de moins de 512o). En pratique la vérité est peut-être entre les deux... En tous cas 1 URE tous les 12,5To lus ne me semble correspondre à rien d'observable : avec un tel taux on devrait rencontrer des URE très régulièrement sur les disques actuels, car lire 12,5To ça arrive assez vite en fait. Or on n'en rencontre pas tant que ça (j'ai des disques de plusieurs années avec des secteurs réalloués, mais aucune URE). Votre avis sur la question ?
  10. Si ce groupe "users" listé dans le shell correspond bien au groupe "users" dans l'interface DSM, il n'est censé avoir aucun accès à ce partage (même pas en lecture, voir premier post)
  11. De passage de en coup de vent chez moi à midi, les fichiers en question tels que vus depuis le NAS lui-même apparaissent ainsi : -rwxrwxrwx 1 admin users 6420768 Feb 15 2015 xxxxxxxxxxxxx.pdf "admin" à cause du mappage NFS, pour le reste rien qui me semble anormal. Enfin, presque... Si je compare avec d'autres fichiers sur des partages accédés seulement en SMB je vois ça (j'ai remplacé le nom de l'utilisateur) : -rwxrwxrwx+ 1 utilisateur1 users 516 Mar 23 20:51 xxxxxxxxxxxxxxx.plist Il y a le "+" derrière les permissions. A investiguer peut-être, mais pas forcément à comprendre ce qui se passe ! Je suis plus utilisateur qu'administrateur... (en l'occurrence le montage est sur un macOS, mais j'utilise aussi Linux).
  12. OK... Pour l'accès SSH ça attendra ce soir, je n'ai pas accès pendant la journée. Information complémentaire : les fichiers qui sont écrits dans ce dossier le sont par l'intermédiaire d'un partage NFS vers mon ordi, avec du côté Syno l'option "mappage de tous les utilisateurs sur admin"
  13. En MP j'ai l'erreur " daffy ne peut pas recevoir de messages. "
  14. Bonjour, j'ai un souci sur les permissions : j'avais créé pour des amis des comptes utilisateurs qui ont accès en lecture seule à un unique dossier partagé, en se connectant par FileStation. Or je viens de me rendre compte que ces comptes peuvent supprimer des fichiers ! Et je ne comprends pas pourquoi... Voilà les permissions de groupes de ce dossier : http://prntscr.com/no4803 ... Les utilisateurs concernés sont dans le groupe "MeMs", qui est en lecture seule. Le seul groupe qui a les droits d'écriture est "Administrators", qui ne contient pas ces utilisateurs. Si on regarde les permissions d'utilisateurs du dossier : http://prntscr.com/no4c0r ... Les deux utilisateurs concernés ont des flèches rouges, et on voit qu'ils n'ont pas de permissions particulières en écriture qui contrediraient celles du groupe. Je ne comprends pas, où est la faille ?
  15. J'imagine que tu es sur un réseau local derrière une box, donc ton NAS n'est par défaut pas visible/accessible depuis l'extérieur. Il ne le devient que si sur la box tu fais une translation de ports vers le NAS. Sauf erreur, sur les syno en extfs4 (comme le 218j) on ne peut pas mettre de quota sur les dossiers partagés. Les volumes sont alors le seul moyen d'appliquer des quotas. Les volumes ont un autre intérêt à mes yeux, qui est d'appliquer des politiques de RAID différentes (avec SHR) suivant le type de données.