Alternativa smbclient para archivos grandes

11

Estoy usando smbclient para transferir un conjunto de archivos grandes (80 GB) todas las noches desde un sistema Linux a un recurso compartido de Windows. Últimamente, por cualquier razón, he estado recibiendo tiempos de espera de E / S:

cli_push returned NT_STATUS_IO_TIMEOUT

lo que hace que la transferencia de archivos activa sea anulada y eliminada del recurso compartido de Windows.

Esto puede deberse al error no resuelto 8498 de Samba (o tal vez no). El sistema de Windows no está bajo mi control, por lo que no puedo instalar un servidor ssh (para usar scp o sftp) y no quiero depender de la implementación de NFS de Microsoft.

¿Existe otra alternativa simple y estándar que me permita mover 80 GB de datos de manera confiable de Linux a Windows a través de la red de manera regular (la red es GB ethernet, por lo que el ancho de banda no es un problema)?

Ex umbris
fuente
considere usar herramientas como rsync con el modo parcial habilitado. Incluso WinScp también debería ayudar. O proporcione un almacenamiento NAS común con NFS en Unix y CIFS en Windows, por lo que no es necesario transferirlo en caso de que sea la misma red. Lo mejor es configurar un torrent, en caso de que la otra red. ;-)
Nikhil Mulley
me encontré con la búsqueda del "programa de transferencia de archivos 123go" en Google
Nikhil Mulley

Respuestas:

9

Intente usar estas opciones de socket en smbclient

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

Copio regularmente archivos de más de 40 GB de Windows al servidor de medios Linux sin error, la tasa de transferencia típica es de 85 MB / s con máquinas conectadas a través de un conmutador gigabit.

bsd
fuente
1
Gracias por esto, esto me libró del error; y copié correctamente un archivo 2G de un Ubunutu a un recurso compartido de Windows.
monojohnny
He intentado esta y otras variaciones de ajustar los valores para SO_RCVBUF y SO_SNDBUF sin suerte. El archivo que intento cargar es de aproximadamente 8 gig en una red local con cero pérdida de paquetes.
mhvelplund
2

Utilizando curl

Estoy ejecutando smbclient versión 4.9.4 tratando de transferir un archivo MiB 97 de Arch Linux a Windows y llamo a smbclient --socket-options='TCP_NODELAY IPTOS_LOWDELAY SO_KEEPALIVE SO_RCVBUF=131072 SO_SNDBUF=131072' como el usuario bsd recomendado todavía falla cli_push returned NT_STATUS_IO_TIMEOUT.

Desde la versión 7.40 , curl admite el protocolo .

Por lo tanto, utilicé esto para cargar moderately_sized_filedesde Linux al servicio OurRemoteDirectoryen la máquina de Windows en 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/

Para mí, curl ha subido el archivo de manera confiable cada vez y también muestra el progreso de carga, lo cual es bueno.

Tenga en cuenta que curl aún no admite la creación de directorios en el host remoto.

En consecuencia, es posible que deba crear /Path/To/Dir/utilizando el siguiente comando (pero smbclient mkdirhasta ahora ha funcionado sin problemas):

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

¿Quizás pueda instalar un servidor ftp en su servidor Linux y pedirle al administrador de Windows que le envíe el archivo todas las noches?

FTP tiene algunas funciones útiles para transferir archivos grandes y un mecanismo de pausa / reanudación. Para un archivo tan grande, debe tener cuidado de no tener un hardware de red que cierre las conexiones inactivas demasiado pronto. Puede cerrar su conexión de control antes de que finalice la transferencia.

Coren
fuente
Los archivos van al revés, desde Linux a Windows
Ex Umbris
0

Si

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

todavía regresa cli_push returned NT_STATUS_IO_TIMEOUT

simplemente agregue una opción de tiempo de espera -t <timeout in seconds>

Me ayuda a copiar archivos enormes (> 200 Tb) de máquinas virtuales

Igor Voskresenskiy
fuente