smbclient альтернатива для великих файлів


11

Я використовую smbclient для передачі набору великих файлів (80 Гб) щоночі з системи Linux на загальну папку Windows. Останнім часом я з будь-якої причини отримую таймаути вводу / виводу:

cli_push returned NT_STATUS_IO_TIMEOUT

що призводить до переривання та видалення активної передачі файлів із спільного доступу до Windows.

Це може бути пов’язано з невирішеною помилкою Samba 8498 (а може й ні). Система Windows не перебуває під моїм контролем, тому я не можу встановити ssh-сервер (використовувати scp або sftp) і не хочу залежати від впровадження NFS від Microsoft.

Чи є інша проста, стандартна альтернатива, яка дозволила б мені регулярно надійно переміщувати 80 ГБ даних з Linux до Windows (мережа - це Ethernet GB, тому пропускна здатність не є проблемою)?


Подумайте про використання таких інструментів, як rsync з включеним частковим режимом. Навіть WinScp також повинен допомогти. Або забезпечте загальне сховище NAS з NFS на Unix та CIFS у Windows, тому не потрібно переносити файли взагалі, якщо це одна і та ж мережа. Найкраще налаштувати торрент, охопити іншу мережу. ;-)
Nikhil Mulley

щойно наткнувся на пошук програми "
123go

Відповіді:


9

Спробуйте використовувати ці параметри сокета на smbclient

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

Я регулярно копіюю 40 + ГБ файлів з Windows на медіа-сервер Linux без помилок, типова швидкість передачі даних становить 85 Мб / с на машинах, підключених через гігабітний комутатор.


1
Дякую за це - цим я позбувся помилки; і правильно скопіював 2G-файл із Ubunutu на Windows Share.
monojohnny

Я спробував цю та інші варіанти коригування значень для SO_RCVBUF та SO_SNDBUF без удачі. Файл, який я намагаюся завантажити, становить приблизно 8 гг по локальній мережі з нульовою втратою пакету.
mhvelplund

2

Використання curl

Я запускаю smbclient версії 4.9.4, намагаючись перенести файл 97 MiB з Arch Linux у Windows, і зателефонував smbclient з --socket-options='TCP_NODELAY IPTOS_LOWDELAY SO_KEEPALIVE SO_RCVBUF=131072 SO_SNDBUF=131072' користувачем bsd, який рекомендується, як і раніше не вдалося cli_push returned NT_STATUS_IO_TIMEOUT.

З версії 7.40 , curl підтримує протокол .

Таким чином, я використовував це для завантаження moderately_sized_fileз Linux в сервіс OurRemoteDirectoryна машині 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/

Для мене curl щоразу надійно завантажує файл, а також відображає хід завантаження, що приємно.

Зауважте, що curl ще не підтримує створення каталогів на віддаленому хості.

Отже, вам може знадобитися створити /Path/To/Dir/за допомогою наступної команди (але до цього часу smbclient mkdirвона працювала без проблем):

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

0

Можливо, ви можете встановити ftp- сервер на свій Linux-сервер і попросити адміністратора Windows надсилати йому файл щоночі?

FTP має деякі корисні функції для передачі великих файлів та механізм паузи / відновлення. Для файлу такого великого розміру вам слід подбати про те , щоб мережеве обладнання занадто рано відключало неактивні з'єднання. Він може закрити ваше керуюче з'єднання до завершення передачі.


Файли йдуть іншим шляхом, від Linux до Windows
Ex Umbris

0

якщо

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

все одно повертається cli_push returned NT_STATUS_IO_TIMEOUT

просто додайте варіант очікування -t <timeout in seconds>

Це допомагає мені копіювати величезні файли (> 200 Tb) віртуальних машин

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.