Aws-cli: s3-Sync behält keine Berechtigungen über Buckets bei

Haben alle Dateien die gleichen Berechtigungen? Denn vorerst könnten Sie den Befehl sync mit --acl ausführen, um Berechtigungen festzulegen. Der derzeit ausgeführte sync Befehl ohne andere optionale Argumente sucht jedoch nicht nach Berechtigungen und stellt sicher, dass das Objekt bei der Übertragung die gleichen Berechtigungen wie das ursprüngliche Objekt hat. Wir müssten ein zusätzliches Argument/Feature hinzufügen, um damit umzugehen.

Nein - wenn alle Dateien die gleichen Berechtigungen hätten, könnte ich das Flag --acl verwenden.

Diese Funktion ist wirklich ein Muss für einen Synchronisierungsmechanismus, insbesondere wenn Sie Tausende von Dateien mit unterschiedlichen Berechtigungen haben und eine echte Synchronisierung zwischen Buckets und nicht nur einer Kopie von Dateien wünschen.

Kennen Sie eine andere Möglichkeit, Berechtigungen pro Datei zu erhalten, damit ich dies leicht genug skripten kann?

Danke fürs Helfen.

Ja, wenn Sie für jedes der Objekte ein aws s3api get-object-acl ausführen. Sie könnten ACLs bekommen. Hier sind die Dokumente für den Befehl.
http://docs.aws.amazon.com/cli/latest/reference/s3api/get-object-acl.html

OK - danke, das wird funktionieren, aber diese Funktion wäre in der Synchronisierung immer noch sehr willkommen, wenn nicht standardmäßig das Flag --preserve-s3-acl in Ordnung wäre.

Kein Problem. Werde die Funktion in Betracht ziehen. Ich glaube, der Grund dafür, dass es nicht implementiert wurde, ist, dass die Operation selbst kostspielig sein kann. Um die Objekte in einem s3-Bucket zu bestimmen, wird ListObjects aufgerufen, dies gibt jedoch nicht die ACLs für jedes Objekt zurück. Im Gegenzug müssten wir für jedes aufgelistete Objekt GetObjectAcl ausführen, was eine Weile dauern könnte, wenn sich Tausende von Elementen im Bucket befinden.

Da es einige Zeit gedauert hat, bis ich feststellte, dass die Berechtigungen nicht synchronisiert wurden, könnte eine Aktualisierung der Dokumentationen von s3 auf s3 sync, um zu erwähnen, dass nur die Daten und nicht die Berechtigungen synchronisiert werden, jemand anderem in Zukunft Zeit sparen.

Danke noch einmal

irgendwelche Updates dazu?

Ich habe vor ein paar Wochen eine Pull-Anfrage (#1535) hinzugefügt, um dies zu beheben (auch andere S3-zu-S3-Transfers, wie copy ). Gibt es eine Chance, es für die Aufnahme in Betracht zu ziehen?

Hallo, ich weiß, es ist ein alter Thread, aber wir haben das durch eine Synchronisierung nach Berechtigungstyp gelöst. Fazit: Sie können Ihre Synchronisierung mit --exclude und --include nach Schlüsselnamen filtern, außerdem können Sie die ACL jeder Synchronisierung angeben ... Wenn Sie also ein Muster von Schlüsseln haben, müssen Sie unterschiedliche Berechtigungen festlegen, führen Sie sync-Befehl oft mit verschiedenen ACLs-Optionen benötigen. Es ist alles andere als ideal, aber es funktioniert!

Irgendwelche Gedanken vom AWS-Team?

Ich schiebe meine Git-Repositorys nur für Backups auf S3. Und wenn ich sie dann wieder synchronisiere, haben sich alle Arten von Berechtigungen geändert.

Alle meine ausführbaren Bin-Dateien sind nicht mehr ausführbar, und git status kreischt darüber.

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1, Ja, ich habe meine Buckets mit einem Punkt benennen lassen, musste geändert werden, um über die Cloud-Front für https kompatibel zu sein. Synchronisiert mit neuen, korrekt benannten Buckets. Kann nicht auf Dateien zugreifen. Lesen Sie mehr über Berechtigungen. Berechtigungen auf Objektebene sind vorhanden. Kein Befehl zum Ändern aller Berechtigungen auf Objektebene in einem Bucket. Fragt sich, wie es weitergeht. Die Berechtigungen über die AWS-GUI sehen in beiden Buckets tatsächlich gleich aus, aber wenn ich die Zugriffskontrollliste über die cli nachschlage, sehe ich, dass der ursprüngliche Bucket einen zusätzlichen Berechtigten hatte, der nicht kopiert wurde.
{
"Stipendiat": {
"Typ": "Gruppe",
"URI": " http://acs.amazonaws.com/groups/global/AllUsers "
},
"Berechtigung": "LESEN"
}

Guten Morgen!

Wir schließen dieses Problem hier auf GitHub im Rahmen unserer Migration zu UserVoice für Funktionsanfragen, die die AWS CLI betreffen.

Auf diese Weise können wir Ihnen die wichtigsten Funktionen zur Verfügung stellen, indem wir Ihnen die Suche und Unterstützung für die Funktionen erleichtern, die Ihnen am wichtigsten sind, ohne die Konversation mit Fehlerberichten zu verwässern.

Als kurze Einführung in UserVoice (falls noch nicht bekannt): Nachdem eine Idee veröffentlicht wurde, können die Leute über die Ideen abstimmen und das Produktteam reagiert direkt auf die beliebtesten Vorschläge.

Wir haben vorhandene Funktionsanfragen von GitHub importiert – suchen Sie dort nach diesem Problem!

Und keine Sorge, dieses Problem wird der Nachwelt zuliebe weiterhin auf GitHub existieren. Da es sich um einen Nur-Text-Import des ursprünglichen Beitrags in UserVoice handelt, werden wir die Kommentare und Diskussionen, die bereits hier zur GitHub-Ausgabe existieren, im Hinterkopf behalten.

GitHub bleibt der Kanal zum Melden von Fehlern.

Auch diese Ausgabe ist jetzt wieder zu finden, indem Sie nach dem Titel suchen unter: https://aws.uservoice.com/forums/598381-aws-command-line-interface

-Das AWS SDKs & Tools-Team

Dieser Eintrag ist speziell auf UserVoice zu finden unter: https://aws.uservoice.com/forums/598381-aws-command-line-interface/suggestions/33168325-s3-sync-does-not-preserve-permissions-across- Bucke

@ASayre - Dies ist möglicherweise der falsche Ort für diese Diskussion, aber könnten Sie erläutern, warum Amazon die Diskussionen in der AWS CLI umständlich auf GitHub und UserVoice aufgeteilt hat?

Funktionsanfragen scheinen hier auf GitHub angebracht. Es ist relativ einfach, nur nach Funktionsanfragen zu filtern und sogar nach den beliebtesten zu sortieren:

GitHub macht es auch einfach, Code-Snippets zu teilen oder auf andere Probleme zu verweisen (wie #1060, das mit diesem zusammenhängt), und ein großer Teil der AWS CLI-Benutzerbasis ist bereits hier auf GitHub aktiv.

Basierend auf dem Feedback der Community haben wir uns entschieden, Funktionsanfragen an GitHub-Probleme zurückzugeben.

Hat jemand eine vernünftige Lösung, um dies zu erledigen? Die dringend benötigte Funktion.

Die obige Antwort zwingt * dazu, öffentlich gelesen zu werden. Dadurch bleiben die Berechtigungen nicht erhalten.

Wie ist der Fortschritt? Ich stoße auch auf dieses Problem. Jetzt verwende ich einfach sync --include/exclude, um dieses Problem zu beheben.

Will mich jemand dafür bezahlen?

4 Jahre und doch geht dieser Albtraum weiter. Ich habe über 10 Millionen Dateien und alle mit Berechtigungen, die beim Kopieren verloren gegangen sind. Wie ist eine so einfache Sache wie das Halten von Berechtigungen möglich?

+1

Für alle anderen, die hierher kommen, konnte ich damit einen Bucket in einen anderen kopieren und ACLs behalten: https://github.com/cobbzilla/s3s3mirror/tree/2.1-stable

Es ist auch deutlich schneller.

Für mich verwende ich derzeit s3, um meine Arbeitsordner zu sichern. Dazu gehören Git-Repos, und meine Repos flippen nach all den Berechtigungsänderungen immer wieder aus.

Für mich bestand die Lösung darin, einen Weg zu finden, nur die Berechtigungen pro Repository zurückzusetzen. Bis AWS ihren Müll behebt, ist dies die Lösung für mich.

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

Die Lösung habe ich hier gefunden:

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

Hi,

Ich bin auf das gleiche Problem gestoßen - ich hatte einen Eimer mit Tonnen von Objekten, von denen einige öffentlich zugänglich sein sollten. Ich musste den gesamten Bucket in einen anderen kopieren, während die ACLs erhalten blieben, und das manuelle Einrichten der ACLs würde mich natürlich viel Zeit in Anspruch nehmen.

Ich habe dieses einfache Skript in Python erstellt, das die Objekte von einem Bucket in einen anderen kopiert und auch die ACLs dafür einrichtet.

Schauen Sie gerne rein:
https://github.com/terminator9999/aws-s3-bucket-copy/