smbclient alternatywa dla dużych plików

11

Używam programu smbclient do przesyłania zestawu dużych plików (80 GB) co noc z systemu Linux do udziału Windows. Ostatnio, z jakiegokolwiek powodu, otrzymywałem limity czasu wejścia / wyjścia:

cli_push returned NT_STATUS_IO_TIMEOUT

co powoduje przerwanie i usunięcie aktywnego transferu plików z udziału Windows.

Może to być spowodowane nierozwiązanym błędem Samby 8498 (a może nie). System Windows nie jest pod moją kontrolą, więc nie mogę zainstalować serwera ssh (do użycia scp lub sftp) i nie chcę polegać na implementacji NFS przez Microsoft.

Czy istnieje inna prosta, standardowa alternatywa, która pozwoliłaby mi regularnie przenosić 80 GB danych z systemu Linux do systemu Windows w sieci (sieć to GB sieci Ethernet, więc przepustowość nie stanowi problemu)?

Ex Umbris
źródło
rozważ użycie narzędzi takich jak rsync z włączonym trybem częściowym. Nawet WinScp powinien również pomóc. Lub zapewnij wspólną pamięć NAS z NFS na Unixie i CIFS na Windowsie, więc nie musisz w ogóle przesyłać, jeśli jest to ta sama sieć. Najlepiej jest skonfigurować torrent, zainicjować inną sieć. ;-)
Nikhil Mulley
po prostu natknąłem się na wyszukiwanie w programie do przesyłania plików 123go w Google
Nikhil Mulley

Odpowiedzi:

9

Spróbuj użyć tych opcji gniazd w smbclient

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

Regularnie kopiuję 40 + GB plików z systemu Windows na serwer multimediów Linux bez błędów, typowa szybkość transferu wynosi 85 MB / s przy maszynach podłączonych za pomocą przełącznika gigabit.

bsd
źródło
1
Dzięki za to - pozbyłem się dla mnie błędu; i poprawnie skopiowałem plik 2G z Ubunutu do Windows Share.
monojohnny
Próbowałem tej i innych odmian dostosowywania wartości dla SO_RCVBUF i SO_SNDBUF bez powodzenia. Plik, który próbuję przesłać, to około 8 gramów w sieci lokalnej z zerową utratą pakietów.
mhvelplund
2

Za pomocą curl

Korzystam z programu smbclient w wersji 4.9.4, próbując przenieść plik 97 MiB z Arch Linux do systemu Windows i wywołując program smbclient z --socket-options='TCP_NODELAY IPTOS_LOWDELAY SO_KEEPALIVE SO_RCVBUF=131072 SO_SNDBUF=131072' zalecanym przez użytkownika bsd nadal nieudanym cli_push returned NT_STATUS_IO_TIMEOUT.

Od wersji 7.40 curl obsługuje protokół .

Dlatego użyłem tego do przesłania moderately_sized_filez Linuksa do usługi OurRemoteDirectoryna komputerze z 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/

Dla mnie curl przesłał plik niezawodnie za każdym razem, a także wyświetla postęp przesyłania, co jest miłe.

Zauważ, że curl nie obsługuje jeszcze tworzenia katalogów na zdalnym hoście.

W związku z tym może być konieczne utworzenie /Path/To/Dir/przy użyciu następującego polecenia (ale jak smbclient mkdirdotąd działało bez problemu):

smbclient //172.16.17.52/OurRemoteDirectory/ -U MyUserName%MyPassword -W OurWindowsDomain -c 'mkdir Path/To/Dir/'
Matthias Braun
źródło
0

Może możesz zainstalować serwer ftp na serwerze linux i poprosić administratora systemu Windows o przesyłanie go wieczorem?

FTP ma kilka przydatnych funkcji do przesyłania dużych plików oraz mechanizm pauzy / wznowienia. W przypadku tak dużego pliku należy zadbać o to, aby sprzęt sieciowy zbyt wcześnie nie wyłączał nieaktywnych połączeń. Może zamknąć połączenie sterujące przed zakończeniem przesyłania.

Coren
źródło
Pliki idą w drugą stronę, od Linuksa do Windowsa
Ex Umbris,
0

gdyby

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

wciąż wraca cli_push returned NT_STATUS_IO_TIMEOUT

po prostu dodaj opcję limitu czasu -t <timeout in seconds>

Pomaga mi kopiować ogromne pliki (> 200 Tb) maszyn wirtualnych

Igor Voskresenskiy
źródło