Aws-cli: s3 sync не сохраняет разрешения для сегментов

У всех файлов одинаковые разрешения? Потому что сейчас вы можете запустить команду sync с --acl чтобы установить разрешения. Однако в настоящее время выполняющаяся команда sync без других необязательных аргументов не ищет разрешения и не гарантирует, что при передаче объекта он имеет те же разрешения, что и исходный объект. Нам нужно будет добавить дополнительный аргумент / функцию, чтобы справиться с этим.

Нет - если бы у всех файлов были одинаковые разрешения, я мог бы использовать флаг --acl.

Эта функция действительно необходима в механизме синхронизации, особенно когда у вас есть тысячи файлов с разными разрешениями и вам нужна настоящая синхронизация между сегментами, а не просто копией файлов.

Вы знаете другой способ получить разрешения для каждого файла, чтобы я мог достаточно легко написать сценарий?

Спасибо за помощь.

Да, если вы запустите aws s3api get-object-acl на каждом из объектов. Вы можете получить acl. Вот документы для команды.
http://docs.aws.amazon.com/cli/latest/reference/s3api/get-object-acl.html

Хорошо - спасибо, это сработает, но эта функция по-прежнему будет очень полезна при синхронизации, если не по умолчанию, флаг --preserve-s3-acl был бы очень хорош.

Без проблем. Рассмотрим фичу. Я считаю, что причина, по которой он не был реализован, заключается в том, что сама операция может быть дорогостоящей. Чтобы определить объекты в корзине s3, выполняется вызов ListObjects однако это не возвращает ACL для каждого объекта. В свою очередь, нам придется вернуться и запустить GetObjectAcl для каждого объекта в списке, что может занять некоторое время, если в корзине тысячи элементов.

Поскольку мне потребовалось некоторое время, чтобы обнаружить, что разрешения не были синхронизированы, возможно, обновление документации s3 to s3 sync, чтобы упомянуть, что синхронизируются только данные, а не разрешения, сэкономит время кому-то еще в будущем.

Спасибо еще раз

какие-нибудь обновления по этому поводу?

Несколько недель назад я добавил запрос на перенос (# 1535), чтобы решить эту проблему (а также другие переводы с S3 на S3, например copy ). Есть ли шанс на его рассмотрение для включения?

Привет, я знаю, что это старый поток, но мы решили это с помощью одной синхронизации по типу разрешения. Итог: вы можете фильтровать синхронизацию по имени ключа с помощью --exclude и --include, также вы можете указать ACL для каждой синхронизации ... Итак, если у вас есть шаблон ключей, вам необходимо установить разные разрешения, запустите команду sync, которая вам понадобится, с разными параметрами ACL. Это далеко не идеально, но работает!

Есть мысли от команды AWS?

Я отправляю свои репозитории git на S3 только для резервного копирования. А затем, когда я снова синхронизирую их, все виды разрешений изменились.

Все мои исполняемые файлы bin больше не являются исполняемыми, и git status кричит об этом.

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1, Да, у меня были мои корзины, названные с точкой, пришлось изменить, чтобы они были совместимы с https через облачный фронт. Синхронизировано с новыми сегментами с правильными названиями. Не могу получить доступ к файлам. Прочтите о разрешениях. Существуют разрешения на уровне объекта. Нет команды для изменения всех разрешений на уровне объекта в сегменте. Хотите знать, как действовать. Разрешения в графическом интерфейсе aws на самом деле выглядят одинаково для обоих сегментов, но, просматривая список управления доступом через cli, я вижу, что в исходном сегменте был дополнительный получатель прав, который не был скопирован.
{
«Получатель гранта»: {
«Тип»: «Группа»,
«URI»: « http://acs.amazonaws.com/groups/global/AllUsers »
},
«Разрешение»: «ЧИТАТЬ»
}

Доброе утро!

Мы закрываем эту проблему здесь, на GitHub, в рамках перехода на UserVoice для запросов функций, связанных с AWS CLI.

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

В качестве краткого руководства по UserVoice (если вы еще не знакомы): после публикации идеи люди могут проголосовать за нее, и команда продукта будет отвечать непосредственно на самые популярные предложения.

Мы импортировали существующие запросы функций из GitHub - поищите там эту проблему!

И не волнуйтесь, эта проблема по-прежнему будет существовать на GitHub для будущих поколений. Поскольку это только текстовый импорт исходного сообщения в UserVoice, мы по-прежнему будем помнить о комментариях и обсуждениях, которые уже существуют здесь по проблеме GitHub.

GitHub останется каналом для сообщений об ошибках.

И снова эту проблему теперь можно найти, выполнив поиск по названию на: https://aws.uservoice.com/forums/598381-aws-command-line-interface.

-Команда разработчиков SDK и инструментов AWS

Эту запись, в частности, можно найти на UserVoice по адресу: https://aws.uservoice.com/forums/598381-aws-command-line-interface/suggestions/33168325-s3-sync-does-not-preserve-permissions-across- баке

@ASayre - Возможно, это неподходящее место для обсуждения, но не могли бы вы пояснить, почему Amazon неловко разделила обсуждения AWS CLI на GitHub и UserVoice?

Запросы функций кажутся уместными здесь, на GitHub. Относительно легко отфильтровать только запросы функций и даже отсортировать по самым популярным:

GitHub также позволяет легко делиться фрагментами кода или ссылаться на другие проблемы (например, # 1060, который связан с этим), а большая часть пользовательской базы AWS CLI уже активна здесь, на GitHub.

Основываясь на отзывах сообщества, мы решили возвращать запросы функций в проблемы GitHub.

Кто-нибудь придумал достойное решение, чтобы это сделать? Очень нужная функция.

Приведенный выше ответ заставляет * быть прочитанным публикой. Это не сохраняет разрешения.

Какой прогресс? Я тоже сталкиваюсь с этой проблемой. Теперь я просто использую sync --include / exclude, чтобы решить эту проблему.

Кто-нибудь хочет платить мне за работу над этим?

4 года, а этот кошмар продолжается. У меня более 10 миллионов файлов, и все с разрешениями, потерянными во время копирования. Как может случиться такая простая вещь, как сохранение разрешений?

+1

Для всех, кто пришел сюда, я смог использовать это, чтобы скопировать одну корзину в другую и сохранить ACL: https://github.com/cobbzilla/s3s3mirror/tree/2.1-stable

Это также значительно быстрее.

Что касается меня, я использую s3 для резервного копирования моих рабочих папок. К ним относятся репозитории git, и мое репо продолжает волноваться после всех изменений разрешений.

Для меня решение заключалось в том, чтобы найти способ сбросить только разрешения для каждого репо. Пока AWS не исправит их хлам, это решение для меня.

git config --global --add alias.permission-reset '!git diff -p -R --no-color | grep -E "^(diff|(old|new) mode)" --color=never | git apply'

Я нашел решение здесь:

https://stackoverflow.com/questions/2517339/how-to-recover-the-file-permissions-to-what-git-thinks-the-file-should-be

Привет,

Я столкнулся с той же проблемой - у меня было ведро с кучей объектов, при этом некоторые из них должны быть общедоступными. Мне пришлось скопировать целое ведро в другое, сохранив списки управления доступом, и, конечно же, настройка списков управления вручную заняла у меня уйму времени.

Я сделал этот простой скрипт на Python, который копирует объекты из одного ведра в другое, а также настраивает для него списки управления доступом.

Не стесняйтесь взглянуть:
https://github.com/terminator9999/aws-s3-bucket-copy/