PierU

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.

Comme je l'ai dit perso ce n'est pas une question d'économie mais de bruit. Même s'il est faible il est tout à fait perceptible dans une pièce calme le soir (le mien est dans le salon). Quant au risque encore faudrait-il le quantifier. Apparemment les specs des HDD 3,5" grand-public tournent autour de 50.000 cycles start/stop (voir exemple ici https://www.seagate.com/www-content/product-content/barracuda-fam/desktop-hdd/barracuda-7200-14/en-us/docs/100686584v.pdf ) : ça laisse quand même une bonne marge (ça fait 13 cycles/jour sur 10 ans). Le tout est de ne pas mettre un délai trop court qui conduirait le disque à passer son temps à s'arrêter et démarrer. Ca, ca dépend totalement des usages de chacun. Oui et non. Tout dépend à nouveau de l'usage qui est fait du NAS.

Peut-être, mais ça ne répond pas à ma question 🙂

Bonjour, Question sécurité, est-il raisonnable de monter un partage SMB du Syno au travers d'internet ? Il y a 15 ans je crois ça ne l'était pas du tout, mais le protocole a évolué... Si oui quels avec quels paramètres sur le serveur, pour une authentification chiffrée (indispensable) ? Pour un transport chiffré (pas forcément indispensable pour mon usage) ? J'ai envisagé aussi webdav, mais je le trouve vraiment peu efficace. Notamment j'ai l'impression que quand on veut accéder à un fichier il est entièrement téléchargé en local avant d'être ouvert (je me trompe ?). Il y a aussi la solution sshfs, mais ça réclame l'installation d'un client sshfs sur les ordis des utilisateurs (et ce n'est pas tout à fait satisfaisant sur certains points).

Bah, euh, finalement ça marche... J'ai regénéré une clef RSA (auparavant DSA), et je l'ai copiée avec ssh-copy-id (auparavant copiée à la main), et c'est bon. Je ne sais pas si c'est la clé DSA ou la copie à la main qui posait problème.

Le moteur je peux comprendre, il force au démarrage. Mais les têtes de lectures ? Elles vont se parquer comme elles le font régulièrement même quand le disque n'est pas en veille (et les specifs sur le nombre de parcages sont très larges). Perso j'ai toujours mis mes disques en veille (principalement pour une question de bruit) sur tous les ordis ou sur le seul NAS que j'ai eu avant celui-ci, et mes 2-3 disques qui ont lâché ce n'était pas à cause du moteur. Par curiosité j'ai regardé sur mon ordi actuel qui a 7 ans 1/2 : dans le rapport SMART le HDD (un WD blue de 500Go) est crédité de 36395 start/stop (13 par jour), et aucune anomalie rapportée. Je pense que si on met un délai raisonnable (pas moins de 30mn), le nombre de cycles reste dans ce peut supporter un HDD pendant plusieurs années.