Aller au contenu

Configuration NAS Synology


Fromgardens

Messages recommandés

Il y a 13 heures, Sethenès a dit :

Je reconnais que contrairement aux "NAS" de NetApp, il n'est pas possible de réduire l'espace alloué à un volume sur un Syno. Dès lors, l'administration demande un peu plus de réflexion. 

Oui. En pratique Il vaut mieux créer les volumes avec la taille dont on a besoin à l'instant T, en laissant de l'espace non alloué, et d'augmenter par la suite les volumes où il y a besoin de le faire.

Lien vers le commentaire
Partager sur d’autres sites

  • Réponses 429
  • Créé
  • Dernière réponse

Top contributeurs dans ce sujet

Top contributeurs dans ce sujet

Posted Images

Le 10/01/2019 à 00:43, Sethenès a dit :

@aexm :

Pour moi le principal intérêt est de segmenter les données par genre et d'allouer l'espace disponible en fonction de ça. Avec pour principal effet qu'en cas de blème (un volume qui s'accroit anormalement), je ne peux pas avoir de "disk full" sur d'autres volumes.

Dans mon cas, si on repart du bas. Le volume 6 est dédié aux machines virtuelles, rien de particulier à ajouter.

Le volume 5 est réservé aux backups des PCs sous Windows et le 4 à celui des Macs.

Le volume 3 contient les données partagées (shares).

Le volume 2 est dédié aux données de paquets Syno comme les fichiers multimédias par exemple (paquet Media Server). Sur le NAS backup, c'est dans ce même volume que sont placés les enregistrements des caméras pilotées par video station (800 GB).

Le volume 1 est réservé aux paquets eux-mêmes et aux données que je ne peux pas déplacer vers le 2. C'est notamment la que Synology implante certaines DB comme par exemple celle de Cloud Station Backup. Attention, pas les fichiers eux-mêmes, mais la DB.

Comme tu l'as peut-être remarqué, les 3 volumes avec des données (j'exclus ici volume 1, volume 6 et le volume "quotas"), ne sont occupés qu'à moins de 50%. C'est totalement voulu, comme ça s'il y a des encryptions par des malwares ou des écrasements, il y a assez de place pour que les anciennes versions des fichiers soient sauvegardées.

Car évidemment, tous les shares sont protégés par des snapshots locaux et des snapshots répliqués sur l'autre NAS. Mais pour ça, il faut au minimum le double de place. Raison pour laquelle il y a 50% de libre. Actuellement, un peu moins de 70% de l'espace disque total est alloué aux volumes (5,5 TB alloués et 2,7 de libre).

Je n'ai pas énormément de données en "GB" mais elles me sont très précieuses et certaines ne datent pas d'hier :

 

Capture d’écran 2019-01-10 à 00.41.53.png

je comprends bien la logique derrière …

Mais en partageant ici l'intégralité des capacités disques sur un seul volume.

Cela ne change rien … ie ce sont les dossiers partagés qui font ce travail et les quota sont au niveau de chaque dossier.

L'exemple donné est une manière de faire comme une autre. Aucun pb.

Mais cela ne me donne pas d'intérêt particulier à le permettre en place.

Comme évoqué plus haut, à part sur des NAS avec 10 disques (par ex.), je ne vois pas l'intérêt de volume.

Pour moi volume = grappe de disques. D'ou ma question sur son intérêt parce que je ne vois pas d'autres intérêts d'usage …

Lien vers le commentaire
Partager sur d’autres sites

Il y a 20 heures, Sethenès a dit :

Je reconnais que contrairement aux "NAS" de NetApp, il n'est pas possible de réduire l'espace alloué à un volume sur un Syno. Dès lors, l'administration demande un peu plus de réflexion.

Mais rien n'empêche de déplacer temporairement des ressources d'un volume à un autre, de supprimer celui-ci et d'en recréer un. La seule condition est d'avoir assez d'espace libre, soit dans les volumes existants, soit de l'espace non alloué. Si je n'avais pas eu cette place, je n'aurais pas pu migrer mes filesystems de l'ancien NAS vers des B-Tree.

Je ne sais pas si vous voyez l'impact que ça a eu sur la migration des données de l'ancien NAS vers le nouveau.

Ici, la migration a été enfantine :

  1. création d'une réplication des données sur le nouveau NAS. 
  2. promotion de cette réplication comme maitre sur le nouveau NAS.

Et c'est tout ... et j'ai tout gardé, dates et heures des fichiers, date et heures d'accès aux fichiers, etc.

Et ça, je ne le savais pas en 2012 quand j'ai configuré l'ancien Syno.

Je te recommande grandement de vérifier avec un outil type Beyond compare en complément après le transfert.

Des fichiers ont été perdus / corrompus lors d'un transfert de meme type.

Et j'avais fait confiance à l'outil …

Certes je ne sais pas si les données étaient corrompues avant le transfert puisque j'ai observé le pb 6 mois après …

… de la complexité des sauvegardes / migrations … sic !

Lien vers le commentaire
Partager sur d’autres sites

  • 4 months later...

J'ai lu quelques articles intéressants sur les problèmes que posent les gros disques (on va dire à partir de 4To) montés en RAID dans les NAS ... Les capacités ont augmenté énormément, mais dans le même temps les débits ont très peu augmenté et les taux d'erreurs de lecture n'ont pas diminué.

Dans une grappe RAID5 il y a un disque de parité, donc une tolérance de panne d'un disque. Quand un disque fume il suffit de le remplacer par un nouveau, et le contrôleur (ou logiciel) RAID reconstruit le contenu du disque. Seulement, pour ça il lui faut relire entièrement tous les autres disques et réécrire entièrement le nouveau. Avec un débit de 100Mo/s, il faut 11 heures dans le meilleur des cas pour remplir un disque de 4To, et en pratique il faut parait-il compter 24h pour la reconstruction d'un disque de 4To. Or pendant tout le temps de reconstruction la grappe n'a plus de redondance et est à la merci de la défaillance d'un autre disque : si cela se produit toutes les données non déjà reconstruites sont perdues.

Le problème est encore accru quand le NAS continue à être utilisé pendant la reconstruction (et c'est un peu le but du RAID de garantir la disponibilité des données), car ce qui ne serait que de la lecture séquentielle des disques intacts pour la reconstruction se transforme en des accès aléatoires. Sur un NAS sollicité H24 en environnement pro cela a deux effets :
- le temps de reconstruction est considérablement augmenté (ça peut prendre plusieurs jours)
- le stress induit sur les disques jusque là intacts augmente le risque qu'ils fument à leur tour !

L'autre problème est que les taux d'erreurs irrécupérables de lecture (URE) n'ont pas diminué. Même si ce risque est intrinsèquement faible, il y a 10 fois plus de chance de rencontrer une URE en reconstruisant un disque de 10To plutôt qu'un disque de 1To. Or quand une URE se produit pendant la reconstruction le contrôleur RAID arrête tout et la grappe est perdue.

D'où la tendance dans les environnements critiques de faire des grappes RAID avec beaucoup de "petits" disque (pas plus de 2To) et avec une redondance de 2 disques ou plus (RAID6) : en cas de crash d'un disque la reconstruction dure moins longtemps, et un deuxième disque peut crasher pendant ce temps sans que les données soient "perdues".

Lien vers le commentaire
Partager sur d’autres sites

il y a 25 minutes, pehache a dit :

Le problème est encore accru quand le NAS continue à être utilisé pendant la reconstruction (et c'est un peu le but du RAID de garantir la disponibilité des données), car ce qui ne serait que de la lecture séquentielle des disques intacts pour la reconstruction se transforme en des accès aléatoires. Sur un NAS sollicité H24 en environnement pro cela a deux effets :
- le temps de reconstruction est considérablement augmenté (ça peut prendre plusieurs jours)
- le stress induit sur les disques jusque là intacts augmente le risque qu'ils fument à leur tour !

C'est l'un des points qui m'a fait hésiter de prendre le 3018xs (6 disques) mais je n'imaginais pas qu'il couterait autant (il a été annoncé en avril pour une sortie en octobre si je me souviens bien). Avec un Raid à 6 disques, j'aurais (en plus du disque de parité) dédié un disque en "spare".

Au niveau professionnel, j'ai eu à deux reprises un disque à remplacer sur une grappe raid mais dans les deux cas, le problème était survenu en dehors des heures de travail et le système l'ayant détecté avait utilisé l'un des disques spares pour reconstruire le raid qui était prêt le matin suivant et ce sans intervention humaine.

A noter qu'il s'agissait de disques spéciaux de "seulement" 137 GB mais en tout nous en avions 42 configurés par grappe de 8-12 avec 2 disques de partié (RAID 4) pour chaque grappe.

Je me suis rabattu sur le ds918+ (qui coute 40% du prix du 3018xs), mais j'ai 2 disques "spares" prêts à être installés dans la machine.

Enfin, on l'a assez répété, le Raid c'est le piège à con. Avec un seul synology, je n'avais rien configuré en Raid par manque d'un backup satisfaisant. Maintenant que j'en ai 2, le principal est configuré en Raid 5, mais pas le second qui est dédié au backup du premier.

BTW, merci pour le retour. C'est vrai que le temps de reconstruction est relativement long. J'ai remplacé préventivement un disque problématique dans le ds918+ et ça a pris une bonne nuit. J'avais isolé le NAS en arrêtant tous les services récurrents : backup, synchronisation, ressources Time Machine, etc.

Modifié par Sethenès
Lien vers le commentaire
Partager sur d’autres sites

il y a 56 minutes, LolYangccool a dit :

Pas rassurant ton message pehache.

Si des disques de 4To sont déjà considérés comme étant gros pour un usage dans un NAS, j'ai peur pour mes disques de 8To...

Même si évidemment, il est conseillé d'un peu attendre avant d'installer la version 7 de DSM lorsqu'elle sera officiellement distribué et qu'elle n'est même pas encore disponible en bêta (donc tablons pour une release officielle d'ici la fin de l'année), Syno a annoncé un processus de réparation plus rapide (seuls les secteurs non vides seraient reconstruits, ce qui accélérerait d'autant plus le processus sur un raid peu rempli).

Ensuite, je suis extrêmement défensif dans mon approche. Même "chargé" mon NAS ne l'est pas. Donc, si j'ai tout coupé, c'est pour encore plus diminuer les risques de problèmes potentiels. Et qu'en plus, ça ne me "coutait" rien de le faire. J'aurais carrément pu enlever le câble réseau, mais ça ne le justifiait évidemment pas.

Au taf, je l'ai écrit, nous avons eu deux disques corrompus et par chance la nuit, mais si ça c'était passé en journée, on aurait du y faire face sur un serveur relativement chargé : 400 utilisateurs pour environ 170 utilisateurs concurrents (homedrive + pool de partage inter-équipe). La notion d'utilisateurs concurrents est claire : il s'agit du nombre minimum de personnes connectées simultanément et qui font des accès fichiers. Le plus risqué et le plus gourmand en ressource étant évidemment les fichiers "ouverts", c'est à dire en cours de modification par l'utilisateur (un document Excel ou Word "ouvert" et dont l'original est stocké directement sur le serveur). A ma connaissance, à part peut être toi, aucun de tes utilisateurs n'édite directement des fichiers sur le serveur. Je serais vraiment surpris que tu aies plus de 5 concurrents users. Cela voudrait dire que plusieurs heures par jour, à chaque moment, 5 personnes téléchargeraient un fichier depuis celui-ci.

Pour en revenir à nos machines avec 170 "concurrent users", en cas de reconstruction "pendant les heures de travail", j'aurais évidemment arrêté les synchronisations, les nettoyages, les backups mais pour le reste, on aurait serré les fesses. Il ne faut pas oublier non plus que même si ce n'est pas idéal, le système Raid est pensé pour ça. Evidemment, entre insérer un disque qui est prêt pour la reconstruction et devoir se poser la question de ce qu'on va faire un vendredi soir si rien n'est prévu et qu'il faut attendre le lundi matin pour passer commande ... 

D'autre part, le backup se trouvant à 10 km du lieu d'exploitation, en cas de gros crash, nous n'aurions eu d'autre choix que de "taper" les serveurs dans une voiture et d'aller les "restaurer" sur un réseau local à côté de l'infrastructure de backup et mes estimations du temps de restoration étaient de l'ordre de la semaine et ça, c'était sans le fait de permettre aux utilisateurs d'accéder à leurs fichiers synchronisés dans l'infrastructure backup. Sinon on en aurait bien eu pour 10 jours (estimation, toujours). Mais de ça, notre hiérarchie était au courant. Evidemment si j'avais été au service informatique d'un hôpital, une telle approche n'aurait pas été suffisante et il aurait fallu investir dans des systèmes bien plus robustes (SAN, ...). 

Tout ça pour dire, qu'à moins que tu aies signé des contrats avec des disponibilités monstrueuses et des temps de réponses fulgurants, tout le monde comprendra qu'en cas de blème, le service puisse connaitre une baisse de performance ou une interruption momentanée. Rien ne t'empêche évidemment, en cas de blême, de suspendre certains accès temporairement (comme ceux que tu offres pour les anciens OS, etc.).

A l'inverse, ce qui ne passerait pas, c'est une absence d'un backup un minimum sérieux parce que la, on est en droit d'attendre ça d'un prestataire de service.

Modifié par Sethenès
Lien vers le commentaire
Partager sur d’autres sites

Après, les temps que j'ai indiqués concernent des disques genre 5400t/mn. Avec des disques 7200t/mn qui ont des débit de 150Mo/s (voire plus) ça va aller plus vite (il faut que le CPU du NAS suive, quand même...)

Modifié par pehache
Lien vers le commentaire
Partager sur d’autres sites

A part ça j'ai un souci sur les réglages de 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 ? 

Lien vers le commentaire
Partager sur d’autres sites

@Sethenès : J’avais détaillé un peu les services qui seraient impactés mais finalement j’avais tout supprimé de mon post pour éviter de faire top de « je raconte ma vie », mais allons-y.

En fait, tout mon réseau passe par mon NAS, c’est le point central et le plus critique de mon réseau. D’une part parce qu’il contient beaucoup de donnée (on parle de plus de 8To) et d’une autre part parce qu’il y a des services vitaux, pour moi j’entends, qui tournent dessus.

Il y a par exemple mon serveur DNS, s’il tombe plus d’accès internet. Ça a la limite je peux changer l’IP du serveur DNS sur le serveur DHCP, donc à la limite c’est pas grave.

Par contre mon NAS est le data store de mes deux serveurs proxmox. Les VMs sont stockés sur le DS1515+ afin de centraliser les données.

Sil tombe, les disques virtuels des VMs tombent aussi et du coup ça induit un arrêt de service de mon site, ma web radio (je travaille avec ma ville pour la relancer, annonce très prochainement, j’ai des réunions en ce moment où je présente le projet et dans lesquelles on travaille dessus, ça devient bon), et d’autres petites choses comme bien sûr mon Synology Drive qui ne synchronisera plus, l’accès à mes fichiers etc...

Concernant la web radio, elle a besoin de deux VMs pour fonctionner H24.

J'ai mon serveur MySQL qui est hébergé sur mon NAS, la VM hébergeant mon site stocke la base de donnée sur le serveur MySQL du NAS.

Ce qui m’embêterai le plus si la panne arrivait, ça serait l’interruption de service du site et de la web radio. Parce qu’elle sera maintenant proposé aussi par la ville, même si elle m’appartient, et que du coup, je ne peux pas me permettre une trop longue interruption de la diffusion. 30 minutes, 1 heure de temps en temps ça peut passer. Mais pas 48h ni même 24h.

Ma web radio va grossir, et ça doit être un minimum sérieux.

Concernant le nombre d’utilisateurs, en fait je suis à plus que 5, mais effectivement, mis à part moi, il n’écrivent pas sur le NAS ou très peu, hormis dans la base de donnée du site et de ma web radio...

Les écritures en DB se font H24 de manière continue mais ce sont surtout des infos du type historique de lecture des musiques diffusées (je garde 1 an d’historique, pour la SACEM), playlist, etc... ainsi que les commentaires postés de temps en temps sur mon site.

En gros je suis en plein travail sur ma web radio (qui va au passage déménager dans un autre local) et la disponibilité doit être élevée sans être forcément exemplaire non plus.

Mais le NAS est sollicité sans interruption, ne serait-ce que par le flux audio qui passe par lui, ou par les accès DB requis pour le fonctionnement de la web radio ou du site.

Modifié par LolYangccool
Lien vers le commentaire
Partager sur d’autres sites

il y a 49 minutes, Fromgardens a dit :

Pour les utilisateurs je ne vois pas du tout d'où ça peut venir c'est étrange.

Tu as essayé de les recréer dans le doute ?

J'ai créé un tout nouvel utilisateur en dehors du groupe concerné, en lui donnant les mêmes permissions, et le problème est le même...

Lien vers le commentaire
Partager sur d’autres sites

il y a 22 minutes, pehache a dit :

J'ai créé un tout nouvel utilisateur en dehors du groupe concerné, en lui donnant les mêmes permissions, et le problème est le même...

Question : peuvent-ils seulement supprimer les fichiers qu'ils ont eux-mêmes crées, ou tous les fichiers présents ?

Lien vers le commentaire
Partager sur d’autres sites

il y a 1 minute, Sethenès a dit :

Question : peuvent-ils seulement supprimer les fichiers qu'ils ont eux-mêmes crées, ou tous les fichiers présents ?

Tous les fichiers.

Ils ne sont pas censés créer de fichiers dans ce dossier (à la base ils ne sont même pas censés pouvoir le faire).

Lien vers le commentaire
Partager sur d’autres sites

@pehache : as tu activé NFS ?

c'est un dossier partagé dont on parle ou un dossier à l'intérieur d'un dossier partagé ?

Je suppose aussi que tu as vérifié que le groupe de chaque user concerné fait uniquement partie du groupe MeMs.

---

Au sujet du RAID, même si @pehache a raison sur le fond (la "norme" va vers le RAID 6 en prod. voire d'autres plus complexes),

N'oublions pas qu'un équilibre doit être maintenu … puisque généralement ce qui coute dans un NAS c'est l'espace de stockage …

Au final, tout cela sera relatif au niveau de SLA de l'utilisateur souhaité (qualité de service et réactivité attendue en cas de panne).

 

Par ailleurs, il est bon de noter/considérer qu'on doit tous disposer d'une voire deux (surtout les pro) sauvegardes.

De fait, si il y a une défaillance (existe mais très rare) lors d'une reconstruction RAID (ça n'arrive pas souvent), elle n'impactera que les structures qui ont besoin de haute dispo.

Et dans ces cas, il n'y a pas uniquement les disques qui sont dans la boucle, la carte mère, l'alimentation etc … peuvent poser pb.

Je pense d'ailleurs (pas de stat. la dessus) que le risque de sur accident lors d'une casse disque est inférieur à une panne carte mère ou alim.

 

De fait, on installe généralement deux serveurs en mode actif/passif par ex. Synology fait ça d'ailleurs.

Mais ce cluster HA doit être physiquement au meme endroit (dans le cas de Synology) i.e sur le meme LAN (pas essayé via VPN pour contourner).

Donc y'a tjrs le pb du feu / foudre / vol etc …

Modifié par aexm
Lien vers le commentaire
Partager sur d’autres sites

Il y a 1 heure, aexm a dit :

@pehache : as tu activé NFS ?

c'est un dossier partagé dont on parle ou un dossier à l'intérieur d'un dossier partagé ?

Je suppose aussi que tu as vérifié que le groupe de chaque user concerné fait uniquement partie du groupe MeMs.

Les utilisateurs en question ne font pas partie d'un autre groupe à part le groupe "users" par défaut (de toutes façons il n'y a que le groupe admin qui a les droits d'écriture). Le problème est le même à la racine du dossier partagé ou dans les sous-dossiers.

Et oui le partage NFS est activé pour ce dossier, avec l'option "mappage de tous les utilisateurs sur admin". C'est par le montage NFS que je mets les fichiers dans ce dossier.

Lien vers le commentaire
Partager sur d’autres sites

Il y a 17 heures, pehache a dit :

Les utilisateurs en question ne font pas partie d'un autre groupe à part le groupe "users" par défaut (de toutes façons il n'y a que le groupe admin qui a les droits d'écriture). Le problème est le même à la racine du dossier partagé ou dans les sous-dossiers.

Et oui le partage NFS est activé pour ce dossier, avec l'option "mappage de tous les utilisateurs sur admin". C'est par le montage NFS que je mets les fichiers dans ce dossier.

D'après les screen, les users feraient partie du groupe MeMs et non User (groupe par défaut).

Le problème de NFS c'est que c'est vite le bordel à gérer. Je ne peux pas faire des essais la, mais l'affichage ne correspondant pas à la réalité, le pb devrait se situer du côté NFS.

Regardes les droits depuis un poste (dossier et sous dossier) avec admin et un user normal.

Y'a également des réglages possibles côté NFS.

Lien vers le commentaire
Partager sur d’autres sites

@Sethenès@aexm@Fromgardens

J'ai résolu mon problème de permissions : les sous-dossiers et fichiers de ce dossier partagé n'héritaient plus des permissions du dossier racine, et du coup c'était les permissions unix qui s'appliquaient (et sur les Syno elles sont en open-bar vu qu'elles ne sont pas censées être utilisées par les dossiers partagés).

J'ai donc simplement réappliqué les permissions du dossier racine à toute l'arborescence (case à cocher dans propriétés/onglet permissions dans FileStation), et c'est revenu en ordre.

Aucune idée de la raison pour laquelle les permissions n'étaient plus héritées, par contre.

 

Modifié par pehache
Lien vers le commentaire
Partager sur d’autres sites

Il y a 4 heures, pehache a dit :

@Sethenès@aexm@Fromgardens

J'ai résolu mon problème de permissions : les sous-dossiers et fichiers de ce dossier partagé n'héritaient plus des permissions du dossier racine, et du coup c'était les permissions unix qui s'appliquaient (et sur les Syno elles sont en open-bar vu qu'elles ne sont pas censées être utilisées par les dossiers partagés).

J'ai donc simplement réappliqué les permissions du dossier racine à toute l'arborescence (case à cocher dans propriétés/onglet permissions dans FileStation), et c'est revenu en ordre.

Aucune idée de la raison pour laquelle les permissions n'étaient plus héritées, par contre.

 

C'est quand même un très sérieux problème que je ne pensais pas voir survenir sur Synology.

Etant dans une configuration bancale pour le moment, je ne peux pas mener tous les tests que je voudrais. Mais dès que ma solution sera stabilisée, j'investiguerai.

Lien vers le commentaire
Partager sur d’autres sites

J'aimerais préciser en quoi le problème pourrait être sérieux.

Soit les droits sont donnés au niveau du share et à ce moment la, tous les fichiers en dessous sont (à la monde windows) "Everyone full control". Le share garantissant que seuls les utilisateurs autorisés peuvent avoir accès au document/répertoire en question. 

Soit les permissions sont données au niveau du système de fichier comme sur une machine unix, mais sur une telle machine, l'utilisateur a ses droits et les conserve quoi qu'il fasse (oublions les su et les sudo).

La où ça devient subtil, c'est qu'en unix, si on déplace un fichier, celui-ci garde les permissions du fichier d'origine alors que si on crée un nouveau fichier, ce fichier prend les droits du répertoire où il est crée.

Donc, si vous suivez bien, tant qu'on crée un nouveau fichier sur un share de type "Everyone full control", il n'y a pas de problèmes.

Par contre si un utilisateur déplace un fichier d'un répertoire partagé où il a accès (lecture seule ou lecture écriture, peu importe) mais que ce fichier est marqué comme en lecture seule au niveau du file-system, alors ce fichier restera en lecture seule quelle que soit les permissions tant au niveau du share de destination que du répertoire dans lequel ce share est crée.

Et donc, des utilisateurs qui ont tous les accès sur un répertoire peuvent se retrouver face à des fichier qu'il leur est impossible de modifier et/ou supprimer. Une vraie "m*rde" pour un sysadm.

Modifié par Sethenès
Lien vers le commentaire
Partager sur d’autres sites

il y a une heure, Sethenès a dit :

C'est quand même un très sérieux problème que je ne pensais pas voir survenir sur Synology.

Etant dans une configuration bancale pour le moment, je ne peux pas mener tous les tests que je voudrais. Mais dès que ma solution sera stabilisée, j'investiguerai.

Ce qui me chiffonne surtout, c'est que je ne vois absolument pas à quelle occasion j'aurais pu faire une fausse manipe qui aurait entrainé cette "faille" de permissions.

Lien vers le commentaire
Partager sur d’autres sites

il y a 1 minute, pehache a dit :

Ce qui me chiffonne surtout, c'est que je ne vois absolument pas à quelle occasion j'aurais pu faire une fausse manipe qui aurait entrainé cette "faille" de permissions.

Je crois que j'ai le même problème sur une de mes ressources ... et je ne comprends pas non plus comment ça se fait !

Lien vers le commentaire
Partager sur d’autres sites

C'est pas File Station qui a foutu le b*rdel ?
Si c'est ça, peut-être essayer de le réinstaller ?
Il m'avait déjà fait une petite frayeur en n'affichant plus mes dossiers partagés.

Pour la réinstallation de File Station https://geekonweb.fr/dsm-6-1-reparer-file-station-sur-un-nas-synology-sil-vous-dit-quaucun-dossier-partage-nest-disponible.html

Modifié par LolYangccool
Lien vers le commentaire
Partager sur d’autres sites

Le 16/05/2019 à 15:23, pehache a dit :

@Sethenès@aexm@Fromgardens

J'ai résolu mon problème de permissions : les sous-dossiers et fichiers de ce dossier partagé n'héritaient plus des permissions du dossier racine, et du coup c'était les permissions unix qui s'appliquaient (et sur les Syno elles sont en open-bar vu qu'elles ne sont pas censées être utilisées par les dossiers partagés).

J'ai donc simplement réappliqué les permissions du dossier racine à toute l'arborescence (case à cocher dans propriétés/onglet permissions dans FileStation), et c'est revenu en ordre.

Aucune idée de la raison pour laquelle les permissions n'étaient plus héritées, par contre.

 

je penche pour NFS, modif. côté utilisateur (volontaire ou soft) … meme si un bug est possible.

j'évite NFS parce que la gestion fine des droits ajoute une complexité sans nom.

De fait, les réglages possibles sont dispo uniquement depuis l'UI DSM. basta

 

Ne pas oublier qu'on est dans des environnements hétérogènes etc …

et que y'a un serveur sous unix, des ordi / idevice en mac / pc / unix derrière … les risquent d'incompatibilité / non respect normes sont grands.

 

cf pb synchro agenda entre NAS, thunderbird et poste pc / mac / smartphone … y'a tt le temps un truc qui plante …

que ce soit google agenda, calendar (synology) ou autre.

idem pour contact.

c'est moins vrai pour outil drive (ca plante moins souvent …disons que ca plante pour d'autres raisons).

 

et ce n'est pas à chaque fois la faute de Synology.

Souvent lié au trop grand nombre mise à jour, de toutes les couches.

 

Modifié par aexm
Lien vers le commentaire
Partager sur d’autres sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Invité
Répondre à ce sujet…

×   Collé en tant que texte enrichi.   Coller en tant que texte brut à la place

  Seulement 75 émoticônes maximum sont autorisées.

×   Votre lien a été automatiquement intégré.   Afficher plutôt comme un lien

×   Votre contenu précédent a été rétabli.   Vider l’éditeur

×   Vous ne pouvez pas directement coller des images. Envoyez-les depuis votre ordinateur ou insérez-les depuis une URL.

Chargement



×
×
  • Créer...