CoolRaoul

Pourquoi ne pas donner le message d'erreur? (désolé mais ça devient systématique les demande d'aide se limitant à "ca ne marche pas, une idée?". Je proposerais bien l'ouverture d'un poste permanent pour un devin extralucide expérimenté chargé de répondre à ce type de question sur le forum mais j'ai peur qu'il n'y ait pas le budget) Donc, en attendant, et pour gagner du temps, essaie de saisir "<addresse ip du nas>" dans la barre d'addresse de l'explorateur (exemple: "192.168.0.50") et dis nous ce que ça donne. PS: s'assurer avoir créé sur le nouveau NAS un compte de nom *identique* à celui qui est utilisé sur le poste Windows et avec le même mot de passe.

En écrivant "ne pas avoir trouvé où ils ont pu valider cette limitation" tu dois te rendre compte que cette "limitation" ne peut être qu'au sein du code source du serveur sftp intégré à DSM Cette partie n'étant pas open source, je ne vois pas très bien ou tu as pu chercher. Et faut bien accepter que, comme la connexion sftp *en root* sous DSM n'a jamais été une fonctionnalité documentée, on ne peut pas reprocher à Synology qu'elle ne "fonctionne pas correctement". D'ailleurs, on ne peut pas s'authentifier sur le compte root non plus en ftp pas plus qu'en cifs et personne ne s'en est plain me semble-t-il.

En ayant activé le nouveau service sftp de DSM les acces sftp devraient marcher (sauf pour le compte root) La seule différence est que les chemins "visibles" seront limités aux répertoires partagés Autres solution, monter sur les Linux les dossiers partagés du NAS en NFS ou CIFS.

Lis bien tous ce qui y a été dit sur le sujet: tu comprendras que c'est la conséquence de l'introduction du service sftp "natif" dans DSM Je vois difficilement Synology décider de revenir en arrière en supprimant ce service pour les quelques utilisateurs faisant du sftp en root (fonctionnalité non supportée officielement) Pour info, "scp" reste possible sur le compte root (sous réserve d'avoir activé ssh), si ça peut dépanner.

Ca doit être pareil que pour les autres NAS de la gamme DS2XX, voir ici:

contentes-toi simplement de taper, dans la boite de dialogue "exécuter" (WIN+R) , ou directement dans la barre d’adresse de l'explorateur: <nom du nas> et, si ca ne marche pas: <ip_du_nas> et tu devrais accéder ainsi aux partages déclarés sur le NAS Et sinon ... *donnes-nous le message d'erreur* please!

Tout ça reste très léger.. En outre, que veux tu dire exactement par "me connecter en réseau local" ? Il y a des bien des façon de se "connecter" sur le NAS (explorateur windows, HTTP ,avec ou sans SSL, ssh, ...) En outre, pour chacune de ces méthodes cela peut se faire en utilisant le nom ou l’adresse IP, ce n'est pas précisé. Et dans tous les cas, ne pas nous indiquer le message d'erreur que tu obtiens n'est pas une très bonne idée. Enfin, à quoi fais-tu allusion spécifiquement en parlant du "menu réseau"?

Vu l'absence quasi totale de détails fournis sur les dysfonctionnements constatés (manipulation effectuées, commandes utilisées, résultats obtenus, messages d'erreurs observés, voire copie d'écran) j'ai bien peur que la réponse soit négative dans l'immédiat

Solution qui ne fonctionne pas non plus: l'indexation des partages réseau n'est pas possible par l'explorateur Windows. Microsoft avait autrefois diffusé un package autorisant cela mais il n'a jamais été upgradé et seule la version 32 bits est restée disponible (et je ne suis même pas sur qu'elle soit compatible avec Windows 7) (*) On trouve ça et la des workarounds permettant d'inclure des partages réseau dans les "bibliothèques" mais les données qu'ils contiennent restent non indexées (chaque recherche parcourt les répertoires à chaque requête) ***EDIT*** (*) des témoignages concordants semblent indiquer que la compatibilité Windows 7 soit effective (mais uniquement pour Windows 7 32bits)

Sur tes propres sujets, tu es autorisé à le faire: cliquer sur "modération", puis "supprimer"

**EDIT** Je viens de voir le lien sur sshfs (ce n'est pas du SFTP au passage) Faut bien prendre en compte que bien que cela ressemble fonctionnellement à un montage de file system, l'utilisation de ssh impose certaines contraintes (en terme de performances, ou du fait que tous les acces sont authentifiés sous un compte NAS unique, celui utilisé pour la connexion) Cela dit, si ça correspond à ton usage, ça me semble tout à fait OK **EDIT #2** Décidément je suis fatigué aujourd'hui: sshfs s'appuie bien sur sftp d'apres la FAQ

Comme dans ton post tu demandais comment *monter un partage* (je cite: "Je ne parviens pas à monter le partage de mon NAS") j'ai détaillé comment le faire avec protocole natif Unix, à savoir NFS (avec SFTP on se contente de faire des copies de fichiers complets ce qui n'est pas la même chose) Si tu avait indiqué ton vrai besoin (copie sécurisée de fichiers à distance) je n'aurais pas proposé cette solution.

Te reste a essayer le script de MrWaloo alors

Et pourquoi ne pas avoir demandé de l'aide sur ce point (à moins que j'ai loupé ton message)? Dans "/etc/fstab" de ton serveur Linux ajoute une ligne par dossier partagé du syno à monter, comme cela <nom ou ip du syno>:<chemin complet du dossier partagé sur le nas> <point de montage local> nfs defaults 0 0 exemple fserv:/volume1/commun /mnt/commun nfs defaults 0 0 Et tes partages seront montés au boot de ton linux automatiquement. (Tu peux monter immédiatement sans attendre tous ce que tu viens de déclarer dans fstab avec la commande "mount -a") Si tu y tiens tu peux toujours faire le montage en ligne de commande: mount -o nfs <host>:<chemin sur le nas> <chemin point de montage local> Pre requis: avoir créé les points de montages ("mkdir /mnt/commun" dans le cas de mon exemple). créer comptes et groupes sur la machine linux correspondant aux mêmes comptes sur le syno en conservant les mêmes numéros, uid et gids. (du moins les comptes et groupes du NAS que tu envisages d'utiliser sur le client Linux). donner l’accès à ta machine linux a chacun des dossiers partagés souhaités en NFS via panneau de configuration -> dossier partagé -> privileges -> privileges NFS. (tu peux y mettre tous le subnet complet avec une syntaxe du genre: <addresse subnet>/<taille masque>, exemple: 192.168.1.0/24) Sauf si l'option "root squash" est désactivée (pas de mappage) le compte "root" du client NFS linux n'a pas acces avec les droits root au fichiers exportés par le NAS (il est vu comme "admin" ou "guest") sur le NAS

Si tu n'as pas peur de mettre les mains sur le cambouis, MrWaloo nous a pondu Mais comme ton besoin est de reconstruire complètement l'index, alors autant faire: panneau de configuration-> Service d'indexage média-> re-indexation

J'ai bien peur que tu n'ais pas testé l'astuce que tu décris: le serveur samba utilisé par DSM ne permet pas d'utiliser le groupe "system" ("système" en français, pas plus que la plupart des groupes windows pré-définis ) sur une entrée d'acl, le résultat obtenu est: Ce que tu décris ne s'applique que sur des répertoires locaux. Et, de toutes façons, sur ces derniers, l'entrée d'acl pour le groupe "AUTORITE NTSystème" avec tous les droits est d'ailleurs présente par défaut sur tous les disques avec héritage automatique.

Je sais que ça ne va pas répondre à ta question mais je me demande pourquoi, pour monter partage d'un NAS tournant sous un Linux (DSM) à partir d'un client Linux (debian) tu as choisis d'utiliser un protocole Microsoft (CIFS) alors que NFS est disponible?

Bon, apparement le problème est résolu dans le dernier firmware: http://www.synology.com/releaseNote_enu/DS212j.php?lang=fre

D'abord installer optware (dit "ipkg" par certains, chercher un peu sur ce forum tu trouvera plein d'exemples) en ensuite "ipkg install lsof"

Comme d'habitude: en ne donnant *ni* la commande ou application utilisée *ni* le message d'erreur obtenu ("timeout", "connection refused", "host does not exists"...) on va pas avancer. PS : tu as bien activé le service SSH au moins?

Test effectué avec succes Ma config: Windows 8 64 Bits Si ca peut être utile voici le contenu des valeurs de la clé HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesWebClientParameters sur ma config: Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesWebClientParameters] "SupportLocking"=dword:00000001 "InternetServerTimeoutInSec"=dword:0000001e "ServiceDllUnloadOnStop"=dword:00000001 "ServerNotFoundCacheLifeTimeInSec"=dword:0000003c "ClientDebug"=dword:00000000 "FileSizeLimitInBytes"=dword:02faf080 "SendReceiveTimeoutInSec"=dword:0000003c "LocalServerTimeoutInSec"=dword:0000000f "FileAttributesLimitInBytes"=dword:000f4240 "AcceptOfficeAndTahoeServers"=dword:00000001 "ServiceDebug"=dword:00000000 "ServiceDll"=hex(2):25,53,79,73,74,65,6d,52,6f,6f,74,25,5c,53,79,73,74,65,6d, 33,32,5c,77,65,62,63,6c,6e,74,2e,64,6c,6c,00 "BasicAuthLevel"=dword:00000001

Précision: je confirme que ça marche mais je faut que je vérifie aussi avec BasicAuthLevel=1

Je testerai ça des que possible (suis pas chez moi là)

Mon PC est sous windows 8 maintenant

A vérifier aussi: si mes souvenirs sont exacts, dans le cas d'une Livebox, l'identification des équipements réseaux (sur laquelle se basent les déclarations de redirections) s'appuie sur l’adresse MAC, qui a forcément changé. Ca peut aussi être une piste