J'utilise smbclient pour transférer un ensemble de fichiers volumineux (80 Go) tous les soirs d'un système Linux vers un partage Windows. Dernièrement, pour quelque raison que ce soit, je reçois des délais d'attente d'E / S:

cli_push returned NT_STATUS_IO_TIMEOUT

ce qui provoque l'interruption du transfert de fichiers actif et sa suppression du partage Windows.

Cela peut être dû au bogue Samba 8498 non résolu (ou peut-être pas). Le système Windows n'est pas sous mon contrôle, donc je ne peux pas installer de serveur ssh (pour utiliser scp ou sftp), et je ne veux pas dépendre de l'implémentation de NFS par Microsoft.

Existe-t-il une autre alternative simple et standard qui me permettrait de déplacer de manière fiable 80 Go de données de Linux vers Windows sur le réseau sur une base régulière (le réseau est en GB ethernet, donc la bande passante n'est pas un problème)?

Essayez d'utiliser ces options de socket sur smbclient

smbclient --socket-options='TCP_NODELAY IPTOS_LOWDELAY SO_KEEPALIVE SO_RCVBUF=131072 SO_SNDBUF=131072'

Je copie régulièrement des fichiers de plus de 40 Go de Windows vers un serveur multimédia Linux sans erreur, le taux de transfert typique est de 85 Mo / s avec des machines connectées via un commutateur gigabit.

En utilisant curl

Je suis en version 4.9.4 smbclient essayant de transférer un fichier 97 MiB de Arch Linux à Windows et appeler smbclient avec --socket-options='TCP_NODELAY IPTOS_LOWDELAY SO_KEEPALIVE SO_RCVBUF=131072 SO_SNDBUF=131072' comme bsd utilisateur recommandé encore échoué avec cli_push returned NT_STATUS_IO_TIMEOUT.

Depuis la version 7.40 , curl prend en charge le protocole smb .

Ainsi, je l'ai utilisé pour télécharger le moderately_sized_filedepuis Linux vers le service OurRemoteDirectorysur la machine Windows à 172.16.17.52:

curl --upload-file /home/me/moderately_sized_file --user "OurWindowsDomain/MyUserName:MyPassword" smb://172.16.17.52/OurRemoteDirectory/Path/To/Dir/

Pour moi, curl a téléchargé le fichier de manière fiable à chaque fois et affiche également la progression du téléchargement, ce qui est bien.

Notez que curl ne prend pas encore en charge la création de répertoires sur l'hôte distant.

Par conséquent, vous devrez peut-être créer /Path/To/Dir/à l'aide de la commande suivante (mais cela smbclient mkdira fonctionné sans problème jusqu'à présent):

smbclient //172.16.17.52/OurRemoteDirectory/ -U MyUserName%MyPassword -W OurWindowsDomain -c 'mkdir Path/To/Dir/'

Peut-être que vous pouvez installer un serveur ftp sur votre serveur linux et demander à l'administrateur Windows de lui envoyer le fichier tous les soirs?

FTP a quelques fonctions utiles pour transférer de gros fichiers et un mécanisme de pause / reprise. Pour un fichier aussi volumineux, vous devez vous assurer de ne pas avoir de matériel réseau fermant trop tôt les connexions inactives. Il peut fermer votre connexion de contrôle avant la fin du transfert.

si

smbclient --socket-options='TCP_NODELAY IPTOS_LOWDELAY SO_KEEPALIVE SO_RCVBUF=131072 SO_SNDBUF=131072'

revient toujours cli_push returned NT_STATUS_IO_TIMEOUT

il suffit d'ajouter une option de temporisation -t <timeout in seconds>

Cela m'aide à copier d'énormes fichiers (> 200 To) de machines virtuelles