s3cmd слишком много раз терпел неудачу

И теперь, в 2014 году, aws cli имеет возможность загружать большие файлы вместо s3cmd.

http://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-set-up.html имеет инструкции по установке/настройке или часто:

$ wget https://s3.amazonaws.com/aws-cli/awscli-bundle.zip
$ unzip awscli-bundle.zip
$ sudo ./awscli-bundle/install -i /usr/local/aws -b /usr/local/bin/aws
$ aws configure

за которым следует

$ aws s3 cp local_file.tgz s3://thereoncewasans3bucket

даст вам удовлетворительные результаты.

Я сам столкнулся с этой проблемой. У меня есть файл 24g.tar.gz для размещения в S3.

Загрузка меньших частей поможет.

Также существует ограничение размера файла ~ 5 ГБ, поэтому я разбиваю файл на куски, который можно повторно собрать, когда фрагменты будут загружены позже.

split -b100m ../input-24GB-file.tar.gz input-24GB-file.tar.gz-

Последняя часть этой строки является "префиксом". Split добавит "aa", "ab", "ac" и т.д. К нему. -b100m означает 100 МБ кусков. 24-гигабайтный файл будет содержать около 240 частей 100mb, называемых "input-24GB-file.tar.gz-aa" для "input-24GB-file.tar.gz-jf".

Чтобы объединить их позже, загрузите их все в каталог и:

cat input-24GB-file.tar.gz-* > input-24GB-file.tar.gz

Принимая md5sums исходного и разделенного файлов и сохраняя это в ведре S3, или, лучше, если он не такой большой, используя такую ​​систему, как parchive, чтобы иметь возможность проверить, даже исправить некоторые проблемы с загрузкой также могут быть полезными.

Я пробовал все остальные ответы, но никто не работал. Похоже, s3cmd довольно чувствителен. В моем случае ведро s3 находилось в ЕС. Маленькие файлы будут загружаться, но когда он дошел до ~ 60k, он всегда терпел неудачу.

Когда я изменил файл ~/.s3cfg, он сработал.

Вот изменения, которые я сделал:

host_base = s3-eu-west-1.amazonaws.com

host_bucket =% (ведро) s.s3-eu-west-1.amazonaws.com

У меня была такая же проблема с ubuntu s3cmd.

s3cmd --guess-mime-type --acl-public put test.zip s3://www.jaumebarcelo.info/teaching/lxs/test.zip
test.zip -> s3://www.jaumebarcelo.info/teaching/lxs/test.zip  [1 of 1]
 13037568 of 14456364    90% in  730s    17.44 kB/s  failed
WARNING: Upload failed: /teaching/lxs/test.zip (timed out)
WARNING: Retrying on lower speed (throttle=0.00)
WARNING: Waiting 3 sec...
test.zip -> s3://www.jaumebarcelo.info/teaching/lxs/test.zip  [1 of 1]
  2916352 of 14456364    20% in  182s    15.64 kB/s  failed
WARNING: Upload failed: /teaching/lxs/test.zip (timed out)
WARNING: Retrying on lower speed (throttle=0.01)
WARNING: Waiting 6 sec...

Решением было обновление s3cmd с помощью инструкций из s3tools.org:

Debian и Ubuntu

Наш репозиторий DEB был тщательно создан в наиболее совместимых путь - он должен работать для Debian 5 (Lenny), Debian 6 (Squeeze), Ubuntu 10.04 LTS (Lucid Lynx) и для всех более новых и, возможно, для некоторых более старых выпусков Ubuntu. Выполните следующие шаги из командной строки:

• Импорт ключа подписи S3tools:

  wget -O- -q http://s3tools.org/repo/deb-all/stable/s3tools.key | sudo apt-key add -

• Добавьте repo в sources.list:

  sudo wget -O/etc/apt/sources.list.d/s3tools.list http://s3tools.org/repo/deb-all/stable/s3tools.list

• Обновите кеш кеша и установите новейший s3cmd:

  sudo apt-get update && sudo apt-get install s3cmd

Эта ошибка возникает, когда Amazon возвращает ошибку: они, похоже, отключают сокет, чтобы вы не загружали гигабайты запроса, чтобы получить ответ "нет, это не удалось" в ответ. Вот почему некоторые люди получают это из-за перекоса часов, некоторые люди получают его из-за ошибок политики, а другие сталкиваются с ограничениями по размеру, требующим использования API загрузки с несколькими частями. Дело не в том, что все ошибаются или даже смотрят на разные проблемы: это все разные симптомы одного и того же основного поведения в s3cmd.

Поскольку большинство условий ошибки будут детерминированными, поведение s3cmd отбрасывания сообщения об ошибке и медленного повторения выглядит сумасшедшим неудачным:(.then. Чтобы получить фактическое сообщение об ошибке, вы можете перейти в /usr/share/s 3cmd/S3/S3.py(помня, что нужно удалить соответствующий .pyc, чтобы изменения были использованы) и добавить print e в блок send_file except Exception, e:.

В моем случае я пытался установить Content-Type загруженного файла в "application/x-debian-package". По-видимому, s3cmd S3.object_put 1) не соблюдает Content-Type, переданный через --add-header, но 2) не может перезаписать Content-Type, добавленный через --add-header, поскольку он хранит заголовки в словаре с case- чувствительных клавиш. Результатом является то, что он выполняет подсчет подписи с использованием значения "тип контента" и затем заканчивается (по крайней мере, с множеством запросов, это может быть основано на каком-то порядке хэширования), отправляя "Content-Type" в Amazon, что приводит к ошибке подписи.

В моем конкретном случае сегодня кажется, что -M приведет к тому, что s3cmd угадает правильный Content-Type, но, похоже, это делается на основе имени файла... Я бы надеялся, что он будет использовать базу данных на основе mimemagic на содержимое файла. Честно говоря, s3cmd даже не может вернуть статус выхода из строя, когда он не может загрузить файл, поэтому в сочетании со всеми этими другими проблемами, вероятно, лучше просто написать собственный одноразовый инструмент, чтобы сделать один вещь, в которой вы нуждаетесь... почти наверняка, что в конечном итоге это сэкономит вам время, когда вас укусит какой-нибудь угловой случай этого инструмента: (.

s3cmd 1.0.0 еще не поддерживает многопоточность. Я пробовал 1.1.0-бета, и все работает отлично. Вы можете прочитать о новых функциях здесь: http://s3tools.org/s3cmd-110b2-released

У меня возникла такая же проблема, она оказалась плохим значением bucket_location в ~/.s3cfg.

Это сообщение в блоге привело меня к ответу.

Если bucket youre uploading to does not exist (или вы пропустили его набрав), itll завершится с ошибкой. Спасибо, общее сообщение об ошибке. - См. Больше на: http://jeremyshapiro.com/blog/2011/02/errno-32-broken-pipe-in-s3cmd/#sthash.ZbGwj5Ex.dpuf

После проверки моего ~/.s3cfg видно, что у него было:

bucket_location = Sydney

Вместо

bucket_location = ap-southeast-2

Исправление этого значения для использования надлежащего имени (ов) решило проблему.

Для меня работало:

В .s3cfg, я изменил host_bucket

host_bucket = %(bucket)s.s3-external-3.amazonaws.com

s3cmd версия 1.1.0-beta3 или выше автоматически будет использовать multipart uploads, чтобы разрешить отправку произвольно больших файлов (источник). Вы также можете контролировать размер куска, который он использует. например.

s3cmd --multipart-chunk-size-mb=1000 put hugefile.tar.gz s3://mybucket/dir/

Это сделает загрузку в 1 ГБ фрагментов.

Найдите .s3cfg файл, как правило, в вашей домашней папке.

Если у вас есть это, вы получите злодея. Изменение двух следующих параметров должно помочь вам.

socket_timeout = 1000
multipart_chunk_size_mb = 15

Я столкнулся с аналогичной ошибкой, которая в конечном итоге оказалась вызвана временным дрейфом на машине. Правильно установите время для исправления проблемы.

В моем случае я исправил это, просто добавив права.

Bucket > Properties > Permissions 
"Authenticated Users"
- List
- Upload/Delete
- Edit Permissions

Я столкнулся с той же ошибкой, что и ошибка группы безопасности, так как политика безопасности была установлена ​​неправильно. Я обвиняю документацию S3.

Я писал о как правильно настроить политику в своем блоге, который:

{
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:ListBucket",
        "s3:GetBucketLocation",
        "s3:ListBucketMultipartUploads"
      ],
      "Resource": "arn:aws:s3:::example_bucket",
      "Condition": {}
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:AbortMultipartUpload",
        "s3:DeleteObject",
        "s3:DeleteObjectVersion",
        "s3:GetObject",
        "s3:GetObjectAcl",
        "s3:GetObjectVersion",
        "s3:GetObjectVersionAcl",
        "s3:PutObject",
        "s3:PutObjectAcl",
        "s3:PutObjectAclVersion"
      ],
      "Resource": "arn:aws:s3:::example_bucket/*",
      "Condition": {}
    }
  ]
}

Я обратился к этому просто не используя s3cmd. Вместо этого у меня был большой успех с проектом python, S3-Multipart на GitHub. Он загружает и загружает, а также использует столько потоков, сколько требуется.