Bonjour,
 
J'utilise un serveur Debian avec des partages samba.
 
Le soucis que j'ai, c'est de savoir comment déplacer des fichiers/dossier du serveur depuis l'explorateur de fichier de windows sans que la copie passe par le reseau(directement en local).
 
Dans l'explorateur Windows je peut déplacer des fichiers mais seulement si j'ai un seul explorateur. Si j'ouvre 2 explorateur(donc des dossiers différents) et que je fait un couper coller sur le même partage la copie passe par le réseau... Alors voila pour des dizaines de Go c'est très gênant.
 
N'y a t'il pas une configuration à faire dans samba ou utiliser un autre explorateur qui gère ça? Ou alors c'est normal?
 
Merci d'avance.
 

Tu n'as pas la main directement sur le serveur Debian ?  
Si ton serveur est sous console, une connexion en SSH, il te suffirait d'utiliser la commande mv.
Si ton serveur a une interface graphique, une connexion VNC/RDP/ce que tu veux, et tu utilises l'explorateur du serveur.

Oui certes, mais bon niveau praticité...
 
avec winscp en ssh mais bon si c'est possible avec l'explorateur de fichier de windows cela serait mieux^^
 
C'est une question de sécurité de samba? ou alors c'est le protocole smb qui est mal fait?

Alors là, sincèrement, aucune idée  
Limite si c'est qu'un problème d'explorateur, euh iSCSI ou un Ajaxplorer sur tes dossiers partagés ?

J'ai essayer en iSCSI mais le problème c'est qu'ont ne peut plus partager avec samba le dd une fois ajouter dans le iSCSI.
 
En tout cas depuis Windows, car il sera formater en NTFS, et sur Debian il ne peut plus le lire.
 
Dommage de pas pouvoir faire du NAS et SAN avec la même partition, il faut surement faire du iSCSI entre un Windows server et Windows 8 pour pouvoir utiliser le disque dans les deux machines.
 
Enfin si l'ont peut... mais ça ne résoud pas vraiment le prob^^, car avec plusieurs utilisateurs le iSCSI devient très complexe.  
 
Bref quand j'aurais trouver comment faire avec samba je le posterais ici.

Hein ?
Tu peut très bien partager une lun SAN sur un réseau, hein.  
L'idée c'est d'avoir un storage processor actif et pas simplement un SP passif comme pour de la virtualisation.
En gros tu aura :
résal <===> SP <===> SAN  
Au lieu d'avoir :
VM <===> Hyperviseur <===> SAN
Le but d'un SAN c'est de mutualiser un réseau de stockage pour des applications, le but d'un NAS c'est d'avoir un stockage en réseau. Sauf que les gens oublient bien souvent qu'on peu faire du NAS avec un SAN (mais pas l'inverse) puisque le but est que le SP, quelque soit le nombre de disques, ne voit qu'un "volume" de stockage avec un filesystem. Partant de ces principes de base du peu faire toi même tes architectures.
Grosso modo ca correspond a ça :  

Grrr, m'enfin mon schema est pas trop exact, vue qu'il est plutôt orienté "gamme du dessus" du SAN encore puisqu'il montre un CFS, chose que le commun des admins sys ne verra jamais.

Merci pour ces details.
 
Par contre une question me turlupine.
 
Si j'ai un  
-Target iSCSI sur un serveur debian
-Initiator iSCSI sur un client windows 8 -> formater en ntfs
 
Le disque lun sur la debian devient donc un disque en NTFS?  
Je sais pas vraiment si c'est l'ideal ensuite pour le partager avec samba comparé a du ext4.

Euh, non. Ton disque dur sur ta deb reste dans le format ou il a été formaté. A la limite la deb, on s'en fou, son rôle, c'est juste de fournir le driver pour les disques, et le TCP qui servira de support au SCSI, mais il te faut un système de boot séparé.
Edit : en gros, ton poste en win8 ne verra que des LUN, il verra pas ce qu'il y a en dessous. Ta deb ne verra pas ton poste sous win8, mais visiblement tu cherche a faire des choses sans savoir réellement ce qu'est un SAN et pourquoi on s'en sert :x
Edit 2 : en relisant ton post, non le SAN est une mauvaise idée pour ce que tu souhaite faire, puisque dans tout les cas, il te faudra passer par un serveur tier qui exposera le partage, et donc nécessairement tu passera par le réseau (c'est même le but d'un SAN : fait passer des opérations disque par le réseau). Donc il te reste le choix d'optimiser ton NAS au niveau vitesse, ou passer par une console.

Bon ben merci pour toutes ces informations. Je viens de comprendre
 
J'essayait de faire à ma sauce, j'ai bien compris le principe mais bon pour du @home c'est un peu overkill je pense.

Pour du @home ou non, faire un iSCSI aujourd'hui ce n'est plus si difficile, d'où ma propal

En effet , Je viens de tester entre debian et windows 8 en 10min c'était reglé.  
Après essai(même si c'est mal) je peut monter le dd dans debian et y faire un partage avec samba, le tout avec le disque partager en iSCSI

Je vois pas bien ce que le iSCSI vient faire dans l'histoire par rapport à la question initiale
Déjà c'est pas au même niveau que Samba, et surtout ça n'empêche pas le fait que la copie s'effectue coté client, et donc utilisation du réseau.
 
Le comportement que tu constates est parfaitement normal, si tu fais une copie de fichiers, même sur un même partage, ça passe par ta machine cliente. Si tu déplaces un fichier d'un partage à un autre (même sur le même serveur) ça passe par ton client. Le seul cas "optimisé" c'est si tu déplaces un (ou plusieurs) fichier(s) sur le même partage, dans ce cas là ça ne transite pas par ton client.

Bah oé, moi y'a n'a pas comprendre non plus <_<

Si rtpmomo peut montrer les résultats  

cf ma première réponse.

Quelle première réponse

  là c'est réellement optimisé, car ça ne passe même pas par Samba.

Oui enfin du coup ça ne réponds pas du tout à la question

Ben si : "comment faire pour qu'une copie, d'un endroit sur le partage sur le serveur à un autre endroit du même partage sur le même serveur, ne passe pas par un client"
CQFD : tu travailles directement sur le serveur.

Tu zappes donc une partie importante de sa question :
"depuis l'explorateur de fichier de windows"

D'où (si tu avais lu en entier le topic) :

S'il existe une meilleure solution, n'hésite pas à la proposer, j'en serais tout autant preneur.

Encore une fois, iSCSI n'a rien à faire là.
Et Ajaxplorer, ça revient à faire du VNC/RDP.

Sa question est de savoir si c'est normal que ça fonctionne comme ça, la réponse est oui. Et non il n'y a rien à faire coté serveur Samba pour changer ce comportement.

Toutes les autres propositions ne sont pas des solutions au problème évoqué, ce sont des contournements, et surtout ça change complètement l'approche.

Et iSCSI ne fait pas parti de ces contournements potentiels.

Pas mieux, et pourtant, pas faute d'avoir expliquée : au mieux tu peu contourner le problème, au pire, tu change d'approche, mais changer d'approche pour aller vers de l'iSCSI et exposer des partages ne changera pas fondamentalement le problème que dès que tu sera sur un client qui n'a pas accès directement au FS, tu passera par le réseau, et même la machine target n'aura plus accès aux disques (ou du moins n'est plus censé y avoir accès : on accède pas a plusieurs sur un FS d'un SAN hormis mettre en place un FS distribué, mais c'est se poser des problèmes pour pas grand chose)

Plutôt que de critiquer "mes" solutions, vous en avez proposé ?  
Je suis preneur de toute meilleure solution, et rtpmomo probablement aussi. A défaut, autant ne rien mettre et passer votre chemin.

Ben, une solution ? On t'explique que y'en a pas, que dans tout les cas, ça sera "juste" un contournement du problème, et que, c'est un peu parler de parallel FS vs non-parallel FS. "La" solution s'il doit y en avoir une, ça serait de mettre en place un FS distribué (façon iSCSI) qui permette l'accès au hard parallélisé et donc mettre en place un système type lustre, GPFS ou portmap/NFS, ce qui dans tout les cas exclu "l'explorateur windows" (enfin pas vraiment mais bon) mais j'imagine mal mettre en place lustre ou GPFS pour une volumétrie aussi petite.
Puisque dans la problématique, même si iSCSI permet effectivement de s'affranchir de "passer" par le réseau pour transférer un fichier sur le même "partage" (on va plutôt dire la même LUN pour l'occurrence), il ne permet plus de partager le fichier et transfert le problème de la machine hôte des disques, vers la machine hôte de la LUN > back to square one. Et en plus ça nécessite de faire le partage non plus au niveau du serveur, mais au niveau de l'initiateur iSCSI, puisqu'une seule machine peut accéder au disque a un même instant T (comprendre envoyer des commandes disque et travailler sur le FS) donc souvent, c'est pire que de rester en mode "NAS" et quand tu as besoin de transférer un fichier d'ouvrir une session RDP (ou SSH) sur le NAS pour faire la copie en direct.
Moralité, notre conseil c'est de ne rien toucher et de se contenter d'un transfert comme ça a été dit auparavant : tu reste en mode NAS et fait tes partages en samba, et quand t'as besoin de transférer un fichier sur le même FS, tu te log en SSH/RDP sur le NAS et fait un mv :x

Pour la problématique initiale, par rapport à Samba, personne n'a répondu. Pour ma part c'est en dehors de mes connaissances par rapport à ce point (pourquoi Samba travaille ainsi), d'où mes propals de différents contournements  
 
A défaut, il n'y a pas mieux que :
- travailler sur le serveur directement (VNC/RDP/AjaxPlorer)
- faire une usine à gaz à base d'iSCSI ou un FS distribué (pour reprendre les termes de MysterieuseX)
 
Problème résolu non ?

Ben si on a répondu
- C'est normal que ça se comporte comme ça
- y a pas de solutions de contournement avec Samba
 
Donc oui, soit il fait la manip directement sur le serveur (VNC/RDP/Ajaxmachin, mais adieu l'explorateur de fichiers pour ça), soit il vit avec

Merci pour toutes ces réponses.  
Si c'est normal pour samba c'est bien dommage .C'est quand même une fonction bien basique.

 
 
J'ai quand même appris ce qu'est le iSCSI tout de même  
Je n'aurais jamais eu de réponse car samba ne permet pas de faire ça
 

 
Merci, c'est bien l'unique solution.

Je vais donner une autre solution que de les déplacer avec mv (même si cela se fait très bien et que c'est une solution à recommander)
 
- installer le serveur ssh sur le debian (bon, il y est )
- installer pcmanfm, excellent gestionnaire de fichiers
- se connecter en ssh -X, ou putty + xming
- lancer un pcmanfm ou deux
 
et voilà un gestionnaire de fichiers moderne et normal (avec des onglets si on veut) qui tourne sur le serveur, avec très peu de dépendances. notamment pas de serveur Xorg sur le serveur, ni de window manager, ni de bureau, yen a pas besoin parce qu'on est en X11, c'est la bécane windows qui remplit entièrement ces fonctions.
assez marrant aussi, le drag'n'drop marche entre deux fenêtres distantes.