CoolRaoul

Peut-être pas assez fermement insérés les disques (je n'ai pas ce genre de problème sur un DS210 qui à le même type de châssis) Sauf si il s'agit des vibrations intrinsèques des disques, mais dans ce cas le NAS n'y est pour rien (il est sur que si tu compare à un SSD ... ) En effet, on trouve assez facilement des témoignages de personnes se plaignant des vibrations de ce modèle:

Ou bien un reverse proxy sur le NAS, avec une déclaration de virtualhost redirigeant vers la page de configuration du routeur. (faudra disposer d'un nom de domaine ou utiliser un service de DNS dynamique qui permet de créer des sous-sous-domaines, celui de Syno est dans ce cas par exemple)

(Il y est possible qu'il y ait quelques erreurs dans ce qui suit sur la partie purement Mac car je ne pratique pas cet environnement) Pourquoi utiliser SMB sur un Mac alors que le DSM du Syno supporte le protocole de fichier natif MacOs (panneau de conf -> Win/Mac/NFS ->"service de fichier mac")? Comment as-tu accédé au répertoire home du compte de l'utilisateur "X" a partir du Mac alors que ta connexion mac -> syno avait été établie en s'authentifiant (j'imagine) sous un autre compte que "X"? Bon, dans *tous* les cas, il faut comprendre que la fonction du dossier "home" est de contenir des fichiers *privés* de l'utilisateur. Il n'est pas fait pour contenir des données à partager entres comptes différents. Dans ce contexte, creer/copier des fichiers dans le HOME d'un compte "A" en état connecté sous un compte "B" n'est pas naturel. (Je n'ai pas pu reproduire le comportement que tu décrit cependant: ayant créé un nouveau compte "frais" pour mes tests, un fichier copié dans son home en étant connecté en admin peut bien être supprimé par l'utilisateur lui-même) Cela dit, pour faire des échanges la bonne approche est de créer un répertoire partagé (et d'ailleurs c'est ce que tu as commencé a faire avec le dossier dit "SHARE", alors pourquoi passer par "home"?) ainsi qu'un groupe (panneau de conf -> groupes) Les différents utilisateurs impliqués dans les échanges seront rendus membre du groupe. On configure les droits d’accès globaux de ce répertoire en fonction des utilisateurs (ou des groupes de ces derniers, c'est mieux). Si tu le souhaites, il est possible de régler plus finement les droits au niveau dossier et fichier via FileStation (menu contextuel "propriétés") pour restreindre plus avant. Et là normalement plus de problèmes.

Microsoft indique une méthode, dans l'aide Windows, pour ajouter des dossiers réseau à une bibliothèque, peut être est-ce la solution à ton besoin. C'est détaillé pas à pas ici. Déplier la section "Pour ajouter un dossier réseau non indexé dans une bibliothèque".

Le fichier qui est dans le home du compte et que tu ne parviens pas a supprimer, il est arrivé la comment? Quel logiciel clients sftp utilises-tu ?

Si tu choisi la dernière solution, je peux te confirmer que mon dongle (PCTV nanoStick 73e) est compatible avec le produit.

Sur un DS212J ca risque d'être un peu serré ... J'ai testé quelques jours la version d'évaluation (sur mon ds210j) et finalement laissé tomber. CF mes posts dans le forum du produit: http://forum.dvblogi...hp?f=69&t=21329 http://forum.dvblogi...hp?f=69&t=21330 http://forum.dvblogi...hp?f=69&t=21333 (C'est le dernier problème qui me gène le plus)

La restriction par IP est utilisée pour restreindre quel client (au sens "serveur" et pas "utilisateur") à le droit d'accéder au partage NFS Par contre, il n'est pas besoin de donner de login/mdp car les accès fichiers sont controlés en fonction des UIDs de comptes sur le client UNIX par rapport au serveur NAS Donc, chaque compte utilisateur de la machine UNIX accédera aux fichiers/répertoires du serveur NAS avec les droits du compte syno de *même* UID (numero de compte) En résumé on monte sous le Linux client le partage NFS de façon *globale* (system wide, au boot) et ensuite chaque utilisateur accède aux données en fonction des droits du compte NAS correspondant. Plusieurs utilisateurs connectés au linux simultanément pourront accéder au même moment aux contenu du partage NFS avec des droits différents. Pas du tout: ce qui se passe en fait est que le serveur FTP du Syno interprète la commande "chmod" en modifiant les ACL afin que le résultat corresponde à ce qui est demandé (ce que je trouve même assez bien foutu). Extrait de la trace du dialogue FTP par FileZilla: Commande : SITE CHMOD 755 subsub Réponse : 200 CHMOD command successful. Tu peux aller vérifier le résultat final avec file station

Voici le genre d'ACL sur un dossier qui permet de faire ce que tu demandes sur les dossiers/fichiers inclus créés par la suite:

Qu'on me corrige si je me trompe mais, quand les ACLs sont activées sur un dossier partagé, elles sont prioritaires sur les "modes" unix (en tous cas c'est ce que montrent les quelques tests que j'ai effectués). Et pas besoin de "directory mode" ou "file mode", suffit de placer des entrés d'acl par défaut (peut même se faire avec file station, pas besoin de Windows pour ça) PS: je suis toujours étonné du nombre de personnes qui choisissent l'option CIFS (protocole plutot orienté Windows) pour se connecter à partir d'un serveur Linux à un NAS Synology (Linux aussi) alors que NFS est disponible et est quand mème plus "natif" dans un mode unix<->unix

Oui, Cocher la case que j'ai encadrée: Mais il fallait faire ça *avant* de transferer les fichier Tu va devoir recommener maintenant! **EDIT** En plus, dans filezilla, l'onglet "jeu de caractères dans l'entrée utilisée pour se connecter au NAS du gestionnaire de sites doit être configuré (de préférence) en "détection automatique" ou "forcer UTF-8"

"ma" réponse (rendre à Cesar, toussa ...)

"Quickconnect" alors peut-être ?

M'étonnerait que cela ait la moindre influence sur les perfs. Par contre, par sécurité, si le dune n'a pas vocation à écrire ou modifier les fichiers du NAS ça ne peut pas faire de mal.

Je ressort ma réponse habituelle dans ce genre de cas: commencer par vérifier (et éventuellement changer) les câbles ethernet (entre le dune et le switch *et* entre le nas et le switch)

Le firewall du syno est-il activé? Si c'est le cas, essayer en le désactivant Si ca marche, après l'avoir re-activé, ajouter une règle comme ci dessous en début de liste:

Ben non: puisque CIFS et NFS n'ont rien en commun comme j'ai dit! Sur le Syno, CIFS s'active ici: et NFS ici: Chacun des deux protocoles peut s'activer indépendemment Si tu n'as que des postes client windows, tu peux faire l'impasse sur NFS Et quant au QNAP je ne connais pas. Cela dit il me semble que tu nous a dit que cela marchait via filestation non? Ce qui signifie que tu n'as rien à modifier.

Les deux protocoles (NFS vs CIFS) n'ont strictement rien en commun (mis a part leur objet: accéder a des dossiers à distance) NFS est le protocole de partage "natif" dans le monde Unix, CIFS est le protocole utilisé dans l'univers Windows La quasi totalité des NAS savent gérer les deux protocoles en mode serveur. En mode client, le Synology ne sait gérer que CIFS via filestation

A mon avis et tout simplement parce que les logiciels commerciaux ne sont pas les plus répandus chez les utilisateurs de Synology. (cf http://hwdmediashare.co.uk/pricing) Et donc, c'est plutot tu coté du support de hwmediashare que tu devrais trouver de l'aide (après tout puisque tu as payé pour le produit, ils se doivent de t'assurer une assistance).

Comme on peut le constater sur ton screenshot ("monter le lecteur distant), filestation de sait monter un lecteur distant uniquement avec le protocole CIFS, pas NFS

Ok, ce n'est rien qu'une petite incompr

Ce qui n'a strictement aucun rapport avec webdav et ne correspond pas a ce que j'ai donné comme indications. "Exécuter -> \\chemin_unc" utilise cifs/smb (le protocole de partage natif de Windows) et pas webdav Cela dit c'est quand meme inquiétant: que donne "ping <nom du syno>" (et non pas l'ip) dans une fenetre de commande? Et mon screenshot ? Je me demande bien quels peuvent bien être ces deux utilitaires: pour ma part je ne connais que l'explorateur et la ligne de commande ("net use") pour faire ça Mais d'abord résoudre le problème de résolution de nom vu ci dessus, je ne serais pas étonné qu'il soit à la base de toutes les autres anomalies.

Le DS106, déjà collector vintage?

Photostation n'est pas un service auquel on peut affecter un port dédié, et la méthode détaillée dans le tuto reverse proxy ne s'applique pas (et tu remarqueras que je n'ai pas évoqué photostation dans mes exemples. Sans doute est-il possible de résoudre le problème avec des règles de rewriting mais la ça dépasse mes compétences Apache. Pour cela Il faudra toujours passer par un bloc VirtualHost avec "ServerName photo.mondomaine.com" mais y remplacer les clause "proxy*" par des clauses "rewrite*" Si tu as le temps et la patience, la doc de référence est ici (C'est un domaine assez touffu car puissant, tellement même que l'on trouve des sites exclusivement dédiés à ça)

Ok, je te laisse compléter alors (je dois avouer pour la redirection auto du http en https ne pas m'être penché sur le problème, toute contribution sera bienvenue). PS: Tu ne nous a pas dit si c'était OK pour audiostation maintenant