Fenrir

Tu peux bidouiller avec les mount loop ou des liens, mais ce n'est pas très propre. Il y a plusieurs post à ce sujet sur le forum.

Le port 7001 ne doit pas être ouvert, soit dans le fw du nas, soit dans ta box

Si tu peux te permettre un reset de DSM (pas la peine de faire un reset des data), c'est toujours mieux. Pour ce qui est de DSM 6.1, je n'ai pour ma part aucun pb avec. nb : regarde tout de même les notes de version, il y a pas mal de changements entre DSM 5 et 5.2 et 6.0 et 6.1 ps : quoi que tu fasses, même rien, le backup est toujours requis

Pour les aspects indexation, upload auto des photos du smartphone et galerie, ça marche très bien, c'est juste cette fichue gestion de droits qui plombe le truc.

Depuis quelques versions de PhotoStation, les comptes de DSM sont automatiquement proposés et il n'est plus possible de créer des comptes locaux La gestion des droits se fait par "album", on défini qu'un album est accessible à : public : tout le monde peut y accéder et on peut donner des droits supplémentaires aux utilisateurs de DSM privé : seuls les utilisateurs DSM avec les bons droits (à choisir dans "Attribuer les privilèges") peuvent y accéder mot de passe : un mot de passe sera demandé C'est à combiner aux permissions qu'on applique au partage photo OU aux permissions qu'on applique via PhotoStation (paramètres->photos: tout en bas) !!!! on ne peut pas faire machine arrière !!!! nb : tous les albums sont automatiquement accessibles en lecture à tous les comptes DSM, sauf s'ils sont dans le 3ème mode (mot de passe) -------------------- Perso ça fait lgt que j'ai tout passé en photostation perso (chaque utilisateur à son propre photostation dans /home/photo) : les utilisateurs choisissent public ou privé et ce qui est privé, l'est vraiment (mais pas possible de faire d’exception) = > c'est tout ou rien => plus ça va, moins il est possible de gérer les droits dans cette appli (déjà que ce n'est pas terrible à l'origine)

Commence par ouvrir un ticket au support Synology, puis en attendant qu'ils répondent (ça peut prendre quelques jours comme une éternité), connecte toi en ssh à ton nas et regarde ce que les fichiers de logs racontent, tu auras peut être un message d'erreur plus explicite : cat /var/log/synoupdate.log J'ai souvenir d'un post similaire, le souci venait d'une URL de mise à jour non fonctionnelle dans un cas très précis, mais je ne le retrouve pas, par contre, si tu en as la possibilité, ça vaudrait le coup de faire passer ton nas par une autre connexion Internet (via un proxy ou un vpn par exemple).

Si tu n'arrives pas à configurer un dns dynamique via 1&1, tu peux parfaitement utiliser un autre fournisseur gratuit présent dans la liste de ton nas. Une fois ton dyndns actif sur un autre domaine, tu auras juste à créer un enregistrement de type CNAME (plus A cette fois) chez 1&1 qui renvoi sur ton dyndns qui fonctionne. Exemple : tu choisis de créer un dyndns en mon-nas-a-moi.synology.me synology.me va automatiquement créer un enregistrement de type A pointant vers ton IP et le mettre à jour en cas de changement de cette derrnière tu vas chez 1&1 et tu créés un enregistrement DNS de type CNAME nas.tondomaine.fr CNAME mon-nas-a-moi.synology.me

Je n'utilise pas la fonction de chiffrement du nas (j'ai mes propres outils pour ça), mais ça ne me viendrait jamais à l'idée de chiffrer l'ensemble des partages, surtout avec un modèle J. Le chiffrement ne protège tes données qu'en cas de vol du nas. Et encore, si le montage est configuré en automatique ...

Architecture différente, à commencer par le cpu et potentiellement le southbridge, donc des limitations matérielles différentes. Mais comme indiqué, les anciens modèles ne sont plus vraiment testés avec les nouveaux disques, sont ça peut marcher tout de même, ou pas ...

http://www.zytrax.com/books/dns/ch7/xfer.html#allow-update je ne dis pas que c'est normal, juste pas grave pour un particulier

C'est un choix à faire entre attendre quelques jours avant de mettre des données sur le nas et perdre quelques jours à essayer (en général en vain) de récupérer des données suite à un crash. Le fait de tester les disques n’empêchera pas qu'ils tombent en panne un jour (ils finiront bien par fatiguer), mais permet de mettre toutes les chances de son coté (les pannes au déballage c'est très fréquent) pour que le nas tourne tranquillement un bon moment. Si tu trépignes d’impatience, tu peux parfaitement mettre un des autres disques dans le nas et commencer à jouer avec. Dès que le scan du premier sera terminé, il te suffira de le mettre en remplacement du disque de "test" (qui devra aussi être testé). À titre personnel je ne test plus les disques depuis des années, mais j'ai tout ce qu'il faut niveau sauvegarde et disques en avance (faites ce que je dis, pas ce que je fais )

Pour le warning, l'interface de Synology ne permet pas de faire autrement, mais ce n'est pas grave pour un particulier (c'est une fonction qui permet à un client de mettre à jour un enregistrement DNS, c'est surtout utile en entreprise).

Si tu as lu les tuto cités précédemment, la plupart des réponses à tes questions y sont. Reste le protocole Bonjour (tu sembles avoir trouvé la réponse), qui ne sert que si tu as des Macs un peu anciens. Et le chiffrement, là il y a 2 sujets : chiffrement des transferts : ça dépend du protocole, à toi de cocher/décocher la bonne case chiffrement des données : c'est à faire sur les partages, mais comme ton nas est un petit modèle, ne le fais que sur les partage "privés" (impôts, fiches de paies, ...), pas sur les vidéos &co https://www.synology.com/fr-fr/products/performance#2bay

Je ne sais pas pour Einsteinium (j'ai ma petite idée), mais pour moi la config est simple : jamais en veille, jamais en hibernation

Pour accéder aux dossiers systèmes, il faut se connecter en ssh, mais ce n'est pas nécessaire normalement, dans le gestionnaire des taches deDSM du peux définir une script à lancer au boot.

ça fonctionne chez certains, peut être une différence de version (samsung, lg, sony, google, .... font leur custo différemment) laisse tomber, ça ne résoudra pas ton pb, mauvaise piste il faut un vrai routeur (pas possible avec une box) tu perds surtout l’intérêt d'être dans le lan en root, pas besoin de vpn, on peut directement modifier les DNS dans la conf Ce comportement est différent en fonction du fabricants, sur mon Nexus 5 les dns fournis par DHCP sont bien pris en compte, sur un S7, c'est ceux de Google apparement, mais je n'ai pas testé les autres méthodes (j'ai juste regardé dans mes logs).

Depuis DSM 6 on ne peut plus se connecter en root avec un mot de passe, il faut utiliser une clef ssh ou se connecter en avec un compte administrateur puis faire sudo -s

Ce que tu demandes est possible avec hyperbackup ou rsync ou synchro du dossier partagé, mais je ferai autrement "gros nas" avec 2 disques en raid1 et sauvegarde sur le petit nas des données importantes, ça te couteras l'espace d'un disque, mais tu auras à la fois ta sauvegarde (important pour tes données) et de la continuité de service (important pour tes caméras)

Les droits ont l'air ok, refais un test et va voir dans les logs le vrai message d'erreur (probablement dans /var/log) ls -larth /var/log puis pour les fichiers les plus récents, cat /var/log/FICHER

0/ pour les données individuelles, tu peux activer l'accueil utilisateur, ça créé un partage "homes" qui contiendra un dossier par utilisateur (en pratique il s'agit aussi de partages) qu'il sera le seul à pouvoir consulter (hors admin) pour les données "multi utilisateurs", créés simplement autant de partage que nécessaire (tu peux en créer 512 sur ton nas, ça devrait aller je pense) pour tout ce qui est video/photo/music, utilise les partages éponymes (ceux de la racine et/ou ceux dans les dossiers "home") ensuite pour l'usage, les 2 options sont possibles (même un mixe des 2), c'est un choix à faire 1/ la "préparation" des disques, ou du moins le scan avec les utilitaires du constructeur reste d'actualité, ça permet d'éviter de mettre des données et de perdre du temps sur un disque qui va peut être assez vite tomber en panne 2/ le raid ne fonctionne pas comme ça, en raid1 (ou shr avec 2 disques), tu travailles sur le groupe de disque, c'est le nas qui choisi quel disque utiliser (parfois il utilise les 2 en même temps) les données sont pas vraiment répliquées (copie d'un disque vers l'autre), elles sont écrites sur les 2 disques en même temps (ou presque) afin de ne rien perdre en cas de panne d'un des disques 3/ rsync marche très bien il y a aussi une appli fournie par Synology qui fait ça avec quelques options en plus (HyperBackup) la copie à la main est à éviter, car le jour où tu vas oublier de le faire, tu auras une panne (loi de Murphy) 4/ achètes un switch, les switchs des box sont de très mauvaise qualité et souvent sources de problèmes (idem pour le wifi) par ordre de préférence : rj45, vraie borne wifi, cpl, pigeon voyageur, wifi des box la suite ici : http://www.nas-forum.com/forum/topic/56401-led-éteintes/ 5/ commence par aller lire le tuto de ma signature (comme conseillé par @Einsteinium dans ta présentation) 6/ créé ta signature sur le forum, ça nous permet de connaitre ta configuration en un coup d’œil

Panneau de configuration\Tous les Panneaux de configuration\Groupement résidentiel Sur cette page tu trouveras plusieurs options (modifier l'emplacement réseau, modifier les paramètres de partage avancé et un utilitaire de résolution de problèmes), essaye de jouer avec. Avec un peu de chance ça va refaire les bons réglages. nb : tu as testé le renommage de ton pc Autre piste, un antivirus (ou un virus) a joué avec les paramètres (c'est d'actualité en plus) Passe aussi un coup de windows update.

J'ai réfléchi un bon moment avant de me rappeler d'un truc => Je pense que c'est tout simplement ton ordiphone qui ne se sert pas des DNS envoyés par le DHCP, mais utilise des DNS codés en dur (au hasard, ceux de Google). Certaines versions d'android on ce détestable comportement. Je n'y fais jamais attention chez moi car j'intercepte toutes les requêtes DNS sortantes et les redirige vers mes propres serveurs. Tu as 5 possibilités dans ce cas (aucune n'est simple, merci Google ) : fixer les DNS manuellement, mais ça impose aussi de fixer l'IP utiliser un vrai nom de domaine combiné à des vues intercepter le trafic DNS vers 8.8.8.8 et 8.8.4.4 pour le rediriger vers ton nas configurer ton android pour passer par un vpn (celui du nas par exemple), dans ce cas la conf dns semble respectée si ton téléphone est rooté, tu as des applis qui permettent de changer les DNS Si tu trouve une autre manière de faire (je n'ai pas beaucoup cherché), n'hésites pas à nous en faire part. ------------ Même si ce n'est probablement pas la cause de ton problème, le .home fait parti des tld que j'éviterai d'utiliser pour des questions de sécurité, plutôt qu'un long discours, un article : https://umbrella.cisco.com/blog/blog/2014/04/23/malicious-gtld-squatting/ Il n'existe que 4 tld dispo pour un usage interne : .test, .example, .invalid et .localhost En pratique, même si dans mon tuto je n'ai été très loquace à ce sujet, il vaut mieux utiliser un vrai nom de domaine de premier niveau ou de second niveau (lan.monvraidomaine.fr). J'ai éditer mon tuto pour être plus explicite à ce sujet.

Que donne le nslookup sur ton pc ?

Il existe sûrement des tuto et des cours, mais je n'en ai pas sous la main. Pour essayer de faire simple, de manière générale on peut placer des droits à différents niveaux : accès réseau : firewall par exemple (pas seulement ip/port, mais aussi en fonction de l'identité de la personne ou d'autres critères), ces droits ne pas liées aux 2 autres partage : c'est géré par le "logiciel serveur", ici il s'agit de SAMBA, c'est à ce niveau qu'est effectuée l'authentification, les règles d'accès sont dans la configuration et ne sont pas liées aux droits des 2 autres système de fichier : les droits ne sont plus dans la conf, mais sur les blocs de données, ces droits sont donc modifiables par les postes clients et ne sont pas liés aux droits des 2 autres => tu as donc 3 endroits où tu peux appliquer un contrôle d'accès, avec plus ou moins de finesse, comme le niveau le plus fin est le système de fichier, si on commence à avoir des besoins complexes, on place généralement les droits dessus et donc on ne s'occupe pas des droits sur les partages Par contre, dans la plupart des cas, des droits simples sur les partages sont suffisant, c'est l'option à privilégier 9 fois sur 10, d'où ma proposition de réorganisation Encore une fois, si les utilisateurs peuvent aussi accéder aux fichiers fia un autre protocole que SMB, par exemple avec FileStation, ce que j'ai indiqué peut ne pas fonctionner, de même, les permissions configurées via FileStation peuvent ne pas s'appliquer, ou pas correctement, aux accès en SMB. Tout ça, si ce n'est pas 100% maîtrisé, peut créer un grand niveau de complexité, des trous de sécurité et des problèmes d'accès. Donc encore une fois, essaye de faire des choses simples, même si tu dois faire quelques concessions.

Au contraire, en faisant ça tu te compliques la vie car ça veut dire qu'un utilisateur ne peut avoir qu'un seul type de droit => pas flexible, pas évolutif Je te recommande une structure de droits indépendante de la hiérarchie administrative sinon à la moindre réorganisation tu risques de devoir tout reprendre à zéro. Essaye par exemple ceci (pour chaque partage, on créé des groupes portant le nom du partage) : partage Direction : groupe grp-Direction-RO (accès en lecture seule) groupe grp-Direction-RW (accès en lecture + écriture) groupe grp-Direction-... (un autre type de droits si besoin) partage Comptable : groupe grp-Comptable-RO (accès en lecture seule) groupe grp-Comptable-RW (accès en lecture + écriture) groupe grp-Comptable-... (un autre type de droits si besoin) ... Si le directeur a besoin d'accéder aux dossiers de la compta en lecture, il suffit de le mettre dans le groupe grp-Comptable-RO (en plus de son groupe grp-Direction-RW) En complément, tu configures les partages pour que les utilisateurs ne voient que ceux auquels ils ont accès (c'est plus clair pour les gens, s'ils voient un dossier c'est qu'ils y ont accès, sinon ils n'ont pas le voir) Ceci n'est pas possible, ou plus précisément pas fiable. Si un utilisateur a le droit de créer et de renommer un dossier il est automatiquement propriétaire de ce dossier, donc il a tous les droits dessus et sur le contenu. nb : ce dernier point peut varier en fonction de l'outil utilisé pour la création (filestation, ftp, nfs et smb auront des comportements différents), par exemple en SMB, tu ajoutes potentiellement les droits NTFS aux droits SMB, en NFS il s'agit des droits Unix ... donc au final tu as des droits qui partent dans tous les sens => il vaut mieux se limiter à un seul système de gestion de droits (si les accès se font principalement en SMB, il faut privilégier les droits NTFS => sur le partage tu mets tous les droits RW à tout le monde en SMB, c'est le NTFS qui sera appliqué) Éventuellement tu peux créer un système de "dépôt" dans lequel les utilisateurs ne peuvent que déposer des fichiers/dossiers