S3 API Supported Actions

DanubeData Object Storage provides S3-compatible storage powered by Ceph RGW. The following tables list supported S3 API actions and known limitations.

Bucket Operations

Object Operations

Object Lock Operations

Object Lock provides write-once-read-many (WORM) retention. See Object Storage security for how modes and retention work.

Multipart Upload Operations

Server-Side Encryption

Presigned URLs

Known Limitations

UploadPartCopy and Server-Side Encryption

UploadPartCopy is not supported for server-side encrypted objects. This applies to all server-side encryption methods (SSE-S3, SSE-KMS, and SSE-C). Attempting a multipart server-side copy of an encrypted object returns a 501 Not Implemented error.

CopyObject is no longer affected. Server-side copies of encrypted objects work normally as of the 2026-08-07 storage platform update, which shipped the upstream fix (Ceph PR #63794, released in Ceph v20.2.3). Only the multipart copy path remains outstanding.

The remaining limitation is tracked upstream in Ceph Tracker #23264.

Impact: S3 clients switch from CopyObject to the multipart copy path for large objects, so move, rename, and metadata-update operations on encrypted objects can still fail above a certain size. The threshold is client-specific — the AWS CLI defaults to 8 MB (multipart_threshold) — and above 5 GB multipart copy is the only option, since CopyObject cannot be used for objects larger than that.

Workarounds:

1. Raise the client's multipart threshold — Keeping objects under the threshold routes them through CopyObject, which now works on encrypted objects. For the AWS CLI: aws configure set default.s3.multipart_threshold 5GB.
2. Client-side encryption — Encrypt data before uploading. The storage backend sees unencrypted blobs, so all copy operations work normally. Tools like rclone (--crypt), Cryptomator, restic, and Duplicati support this.
3. Download and re-upload — Instead of a server-side copy, download the object and upload it to the new location.

We are tracking the remaining upstream fix and will update this page when it is resolved.

Control characters in object keys

Avoid control characters in object keys. They are the characters with ASCII codes 1 to 31 other than tab, line feed and carriage return, such as \x01. A key like that is stored, and GetObject and HeadObject read it back. But several responses repeat the key as XML text, and XML 1.0 cannot hold these characters, so a client with a strict XML parser cannot read those responses. We tested the AWS CLI (versions 1 and 2), boto3, the AWS SDK for PHP and the MinIO client (mc): all of them fail. The AWS SDK for JavaScript v3 (version 3.700 in our test) read the listing and CreateMultipartUpload responses we tried.

The failure looks different in each client. The AWS CLI and boto3 take the response for a server error, retry it and report An error occurred (500) when calling the ListObjectsV2 operation (reached max retries: 4): Internal Server Error (max retries: 2 in AWS CLI version 2), although the request itself succeeded. The PHP SDK reports Error parsing XML, and mc reports XML syntax error on line 1: illegal character code U+0001.

What works with such a key: PutObject up to your client's multipart threshold, GetObject, HeadObject, DeleteObject, and CopyObject from it.

What fails in a client with a strict XML parser:

• Listings. ListObjectsV2 fails on a page that ends on such a key when more keys follow, because that key is sent back as the position of the next page, and on a request that starts after one. ListObjects and ListObjectVersions fail on the request that continues after one. A client that does not ask for URL-encoded keys (encoding-type=url) fails on any listing that contains one. The AWS CLI and boto3 ask for them by default; the AWS SDK for PHP does so only for ListObjects, so set EncodingType yourself on ListObjectsV2 and ListObjectVersions.
• Multipart uploads. CreateMultipartUpload, ListParts and CompleteMultipartUpload fail for such a key, and so does ListMultipartUploads while an unfinished upload of such a key is among those listed. An object above your client's multipart threshold (8 MB for the AWS CLI) therefore cannot be uploaded under such a key, and each failed attempt leaves unfinished uploads behind, one for every try. Such a client cannot list them either, so it cannot abort them by hand. A lifecycle rule that aborts incomplete uploads after a number of days should remove them, and you do not have to list them.

What fails with every client we tried, including the AWS SDK for JavaScript v3:

• Multi-object delete. DeleteObjects cannot name such a key: the request is refused with 400 Bad Request and nothing in it is deleted, not even a key without control characters. Delete the objects one at a time with DeleteObject.

What to do: name new objects with a printable separator such as _, -, ~ or /. If you have to keep working with objects that already have such a key, raise the AWS CLI's multipart threshold so that it uploads and copies them with a single request, which works up to 5 GB: aws configure set default.s3.multipart_threshold 5GB (the same setting that works around the UploadPartCopy limitation above). To rename an object, copy it to the new name with CopyObject and delete the old one with DeleteObject.

Questions? Contact support at support@danubedata.ro