PierU

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.

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 ?)

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.

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.

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 ?

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)

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).

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"

En MP j'ai l'erreur " daffy ne peut pas recevoir de messages. "

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 ?

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.

Bonjour, Quand on fait des modifs manuelles dans /etc/ssh/sshd_config, quelle est la persistence de ces modifs ? Y-a t'il un risque que le fichier original soit remis par DSM à une occasion ou une autre ? J'ai vu qu'un reboot conservait les modifs. Est-ce que c'est garanti aussi lors des MAJ ?

Est-ce que l'accès SFTP est toujours activé sur le NAS ? SSHFS utilise en fait SFTP

Salut, Le VPN est une solution, mais je ne pratique pas donc je ne peux pas répondre à ton problème. Une autre solution c'est de faire un montage sshfs. Pour ça il faut installer sur ton Mac FUSE for macOS et SSHFS, dispos tous les deux ici : https://osxfuse.github.io/ activer le service SFTP (à ne pas confondre avec FTPS) sur le NAS (je pense qu'il faut aussi activer le service SSH) sur ton routeur, rediriger un port vers le port 22 du NAS (choisis de préférence un port différent de 22 et au-delà de 1024), mettons 2222 une IP fixe ou un domaine (avec dyndns) qui pointe avec ta box depuis internet Pour monter les dossiers partagés du NAS sur ton Mac, il faut depuis un terminal taper les commandes (en remplaçant "user" et "mondomaine" par ce qu'il faut) : mkdir ~/Desktop/monNAS sshfs user@mondomaine:/ ~/Desktop/monNAS -p 2222 Voilà, tu devrais alors voir "monNAS" sur le bureau apparaitre comme un disque réseau contenant tous tes dossiers partagés. Pour démonter le disque, taper dans le terminal : umount ~/Desktop/monNAS Important : en ouvrant ainsi le port SSH/SFTP sur le routeur, tu dois t'assurer que TOUS les utilisateurs déclarés sur le NAS ont un mot de passe fort, sinon c'est ouvrir la porte aux hackers de toutes sortes (une alternative est de configurer SSH pour se connecter sans mot de passe avec un jeu de clef publique/privée). Une autre alternative serait d'utiliser directement le partage SMB sur internet, mais la sécurité reste une question sans réponse claire pour moi : https://www.nas-forum.com/forum/topic/61747-accès-smb-par-internet/

😉

Non, je n'ai pas essayé... Pourtant c'est ce que j'aurais fait sur une machine unix classique ! Mais j'ai l'impression que les interactions entre les permissions FileStation (ce sont des ACL ?) et les permissions unix ne sont pas très prévisibles... Bon, j'essayerai. Oui c'est ce que je prévois, mais ça oblige les correspondants à conserver le lien au chaud, c'est moins simple.

J'ai trouvé une solution... Ajouter dans /usr/local/etc/nginx/sites-enabled un fichier "custom.conf" en mettant dedans : autoindex on; Mais je n'ai aucune idée de la portée de cette configuration : probablement tous les sites gérés par le serveur, ou tout au moins tous les sites créés par l'utilisateur ? Je voudrais restreindre la portée à un seul site, si possible.

Bonjour, Je veux créer un petit site web pour lequel j'ai besoin que le contenu des dossiers n'ayant pas de index.html soit listé. Avec Apache c'est simple, il suffit de mettre un .htaccess à la racine du site avec "Options All +Indexes". Par contre j'aimerais que le serveur soit NGINX histoire de ne pas à avoir à faire tourner Apache en plus, mais comment le faire avec NGINX ? J'ai lu qu'il fallait ajouter "autoindex on" dans un fichier de configuration, mais je galère à trouver quel fichier de configuration en pratique ? En pratique pour ce site web j'ai créé dans WebStation un VirtualHost. Où sont les fichiers de conf spécifiques à un Virtual Host ?

Ca fonctionne aussi avec les permissions unix classiques, d'ailleurs...

Donc ce n'est pas possible de faire une "boîte de dépôt" ? Dommage... Ce genre de truc fonctionne sur Windows en jouant avec les permissions NTFS : on peut donner des droits tels qu'il est possible de mettre un fichier dans un dossier, mais pas de consulter le dossier.

Bonjour, Dans un dossier partagé classique, je voudrais créer une "boîte de dépôt", c'est à dire un sous-dossier "DEPOT" dans lequel les utilisateurs peuvent copier/uploader des fichiers, mais qu'ils ne peuvent pas consulter. Pour ce faire je suis allé dans propriétés/permissions de ce dossier, j'ai sélectionné dans "avancé" "Exclure les permissions héritées", et j'ai défini des permissions spécifiques à ce dossier : lecture/écriture pour les admin, et écriture seule pour tous les autres utilisateurs : https://i.imgur.com/w3IXeKs.png Mais ça ne marche pas... Je me connecte à FS avec un utilisateur non admin, je fais un clic droit sur le dossier puis "transférer vers DEPOT", et ça me dit que l'utilisateur ne dispose pas des droits... Une idée du pourquoi ou de ce qu'il y aurait à faire d'autre ?

Ils sont quand même très affirmatifs sur l'utilisation possible sur des réseaux qui ne sont pas de confiance (untrusted networks)... Il faudrait sans doute demander aux développeurs de samba comment ils voient les choses de leur côté.

samba lui-même supporte SMBv3.1.1 depuis sa version 4.3 en 2015 : https://en.wikipedia.org/wiki/Samba_(software) La version de samba sur mon DS418j avec DSM à jour est la 4.4.16 : $ sudo smbstatus -V Version 4.4.16 Synology Build 23824, Oct 26 2018 19:47:01

je suis tombé sur cette discussion reddit (en anglais), qui donne plein d'arguments tout à fait censés contre l'utilisation de SMB, même en v3, sur internet : https://www.reddit.com/r/sysadmin/comments/6wvvcm/experts_help_us_understand_smb3x_inflight/ L'argument le plus évident étant que SMB -quelle que soit la version- n'a jamais été pensé pour cet usage par Microsoft. Sauf que... MS utilise bien SMB3 pour les partages de fichiers sur son cloud Azure : https://docs.microsoft.com/fr-fr/azure/storage/files/storage-how-to-use-files-windows Azure étant ultra-important dans leur stratégie, ils ne peuvent pas se permettre d'être négligents avec la sécurité, et ils ont apparemment suffisamment confiance en SMB3 pour le faire utiliser à leurs client au travers d'internet... Après, je suppose que tout est question de configuration côté serveur, c'est là qu'il faut être très rigoureux.

La sécurité ce n'est pas une recette unique qui donne 0% de risque (ça se saurait), et on ne met pas en oeuvre les mêmes solutions suivant ce qu'on a à protéger. Que le VPN soit potentiellement plus sécurisé que le SMB en direct je veux bien le croire, mais ce que je veux évaluer c'est le niveau de risque du SMB en direct. Dans mon cas le VPN présente quelques inconvénients, donc je regarde quelles sont les autres solutions. Le problème c'est que j'ai l'impression que SMB se traîne une mauvaise réputation (méritée, certes) du fait que les premières versions n'intégraient aucune préoccupation de sécurité, et du fait que l'implémentation de MS a toujours été pas mal trouée. Mais quand je lis des trucs sur SMB3 ça a l'air quand même assez sérieux au niveau authentification et chiffrage (sachant que pour ce qui est prévu à la limite il suffit que l'authentification soit safe (les fichiers qui doivent transiter sont soit totalement non confidentiels, soit chiffrés à la source)). Par ailleurs samba n'est pas l'implémentation de MS.