Configure account capabilities

Use capabilities and compatibility policies to adapt S3Client commands and requests to the features your S3 service supports.

Capabilities describe the S3 features supported by the service. Policies specify the requests and values accepted for a bucket, its region, or its endpoint. These settings tell S3Client which options to offer; they do not grant permissions or enable features on the service.

The provider preset supplies the account’s initial values. Amazon S3 configures the features supported by Amazon S3. S3-compatible storage disables optional capabilities and provides a basic configuration to complete for your service. Custom presets use the values in their files. Check these settings: S3Client does not automatically detect available features. You can also explicitly apply a preset to existing accounts to replace their service settings.

Basic shared actions, such as reading and uploading objects, do not all have capability checkboxes. Disabling an option may hide or restrict dependent commands, but does not remove data or configuration already present on S3.

Open and save the settings#

1. In the main window, choose File > Accounts….
2. Select the account and click Edit….
3. In Account, open Capabilities.
4. Select a category from the list on the left.
5. Check supported capabilities or edit the relevant policy. An unchecked box declares the feature unavailable; hover over or select a row to read its explanation.
6. Click OK in Account to save, or Cancel to discard all changes.
7. Reopen the relevant properties or command to check the options offered for that bucket’s context.

Incompatible settings may be rejected with details. Invalid ACL policy: makes OK and Test connection unavailable. A connection test does not validate every capability: it checks only a read request. See Add and manage accounts.

General#

Transfers#

An existing account without Copy only if the source ETag matches and Copy parts only if the source ETag matches keeps them disabled, including an Amazon S3 account. Installing or replacing a preset does not change that account; enable the capabilities in its configuration if the service supports them, or explicitly apply a suitable preset.

Source conditions use the destination account’s settings, even when a copy uses the other account’s credentials. Disabling them retains preliminary checks but permits copying a source changed afterwards; a multipart copy can combine revisions. This also affects moves and rewrites. Download, destination and deletion conditions remain independent. See S3 copy conditions.

Listing & deletion#

Disabling Multipart upload, Object listing (ListObjectsV2), Delete multiple objects, or Object versions automatically unchecks and disables dependent capabilities. Enabling them again does not automatically recheck those dependencies.

Data protection#

The three versioning capabilities are independent: Object versions provides access to versions, Read bucket versioning reads the bucket state, and Change bucket versioning changes it. Enabling a capability neither changes the bucket nor grants remote permissions.

Object Lock capabilities require Object versions. All except Create buckets with Object Lock and Read bucket Object Lock also require Read bucket Object Lock. Change object retention requires Read object retention; Change object legal hold requires Read object legal hold.

For Backblaze B2, enable Object versions and Read bucket versioning, but leave Change bucket versioning off.

Leave Existing-bucket activation token (only if required by the service): empty unless the service requires a value to enable Object Lock on an existing bucket, such as 1 for Backblaze B2. This is not an access key. S3Client does not send it during bucket creation or when changing default retention.

Object tags#

Configure Read tags and Tag editing separately:

• Unavailable: the corresponding read or edit operation is unavailable.
• Current object only: the feature targets the current object without versionId.
• Current object and specific versions: it also targets a selected version using versionId.

Editing requires reading the same targets. Increasing Tag editing also increases Read tags when necessary; reducing Read tags reduces Tag editing when necessary. Available reading with Tag editing > Unavailable lets you view tags without editing them.

Remove tags selects the request used to clear tags: DeleteObjectTagging or PutObjectTagging with an empty TagSet. S3Client selects the method before the operation and does not try another method after a refusal.

Current object verification selects how S3Client checks that the tags it read belong to the current object:

• Response version header uses the version identity returned with the tags without an additional HEAD check. This is the Amazon S3 setting.
• Versioned read and HEAD check requires Read tags > Current object and specific versions. When a current-object observation identifies a version, S3Client reads its tags with versionId, then adds a HEAD to check that it is still current. This requires version tag read and HEAD permissions, notably s3:GetObjectVersionTagging and s3:GetObject on Amazon S3. A contradiction or a missing object stops the operation.

Selecting Versioned read and HEAD check automatically sets Read tags to Current object and specific versions. Reducing that scope restores Response version header. Versioned read and HEAD check keeps the logical target: a current-object change still omits versionId. An immutable exact version does not add this HEAD; a mutable null version must also retain the same content identity. These checks do not make a read followed by a write atomic.

Send tags with PutObject and Send tags with CreateMultipartUpload separately declare support for sending tags with content, including relayed and multipart copies. These options do not enable Multipart upload and do not require editing existing tags.

CopyObject tags offers:

• Unavailable: sending tags with CopyObject is unavailable.
• Independent metadata and tagging directives: metadata and tagging directives can be selected independently.
• Tagging directive must match the metadata directive: the directives must match. When replacing metadata, S3Client reads the source tags before copying so it can send and preserve them. This requires source tag reading and the corresponding permissions; source tag editing is not required.

A simple copy that preserves both metadata and tags on the server does not require this additional read. See properties preserved during copies.

Bucket tags#

Tag editing API offers:

• Unavailable: no reading or editing of bucket tags.
• S3 bucket tagging API: GetBucketTagging, PutBucketTagging, and DeleteBucketTagging for general purpose buckets.
• S3 Control resource tagging: ListTagsForResource, TagResource, and UntagResource. Configure Account ID and S3 Control routes in the account connection settings. Reading and editing tags remain unavailable until the configuration is complete.

Bucket creation#

Object Ownership#

These settings are separate from ACL policy. A policy declaring ACLs available does not make them editable in a bucket where BucketOwnerEnforced disables them. See ACLs and object ownership.

Policies by context#

Encryption policies, Storage classes, Lifecycle, and Static website hosting support multiple policies. Policy selects the one you are editing; Account default policy selects the one used when no more specific assignment matches. Changing Policy alone does not change the default.

Buttons for adding, duplicating where available, and removing policies are beside Policy. Each family accepts up to 32 policies, with unique identifiers. Keep at least one policy. To remove a policy used in Assignments, first remove or change its assignments. In Storage classes and Encryption policies, also choose another default before removing the default policy; in Lifecycle and Static website hosting, the first remaining policy becomes the default if you remove the previous default.

To create a policy in Storage classes, click the add button beside Policy, enter Policy identifier in Add storage class policy, and click OK. The new policy initially contains a STANDARD class. In the other three categories, Add generates the identifier: configure Features before making the policy the default or assigning it. Options start unchecked, except for the two rule statuses and three versioning states under Lifecycle > Rule constraints; adjust these to match your service. Duplicate, available in Encryption policies, Lifecycle, and Static website hosting, copies the selected policy’s settings under a new identity.

To assign a policy:

1. Open Assignments in the relevant category.
2. Click Add or Add…, depending on the category.
3. In Policy assignment, choose Applies to and Policy.
4. Complete the displayed fields according to the criteria below.
5. Click OK to add the assignment, then OK in Account to save.

S3Client applies only the policy from the matching assignment with the highest priority in this table. If none matches, the default policy applies. Use the region code, not its local name; the endpoint is a hostname without a scheme or path. Bucket kind offers General purpose, Directory, and Outposts. Choosing a bucket type specifies where the policy applies; it does not by itself allow S3Client to browse that type of bucket.

Assignments cannot duplicate exactly the same criteria. Each family accepts up to 1,000 assignments. Select a row and use Edit or Edit…, depending on the category, to change it, or Remove to delete it.

Encryption#

In the Object encryption modes list, the SSE-S3, SSE-KMS, DSSE-KMS, and SSE-C checkboxes declare available object encryption modes. In the Encryption API operations list, Read bucket encryption, Set bucket encryption, and Remove bucket encryption configuration separately declare APIs for default bucket encryption. Update object encryption without copying declares UpdateObjectEncryption, which changes encryption without copying the data.

Encryption policies#

In this category, open Features and select the policy to edit under Policy. The options specify the requests and parameters accepted by that policy. These checkboxes do not replace the general capabilities or required KMS permissions:

SSE-C requires supplying the key for the relevant operations; this setting does not store the key. Choose the default policy or assignments appropriate for the bucket before saving.

Storage classes#

A policy describes storage class names actually accepted by the service, the operations offering them, access to archived objects, and allowed lifecycle transitions. Adding a class in S3Client does not create a class on the service.

In Classes, choose Default class, then use Add…, Edit…, or Remove on the list. To add or edit a class, enter Storage class name in Storage class, configure the following fields, and click OK:

Class names are unique within a policy. Before removing the default class, select another; before removing a class referenced by a transition, remove it from that transition. Each policy is limited to 100 classes and 1,000 transitions.

Enter the exact name accepted by the service, using ASCII characters without spaces, up to 256 characters. A new class starts with the placeholder name NEW_CLASS, Always direct access, no upload or copy operations selected, Change storage class on the same object unchecked, and Unsupported restoration. Replace the name and configure the operations before saving. Renaming a class updates its references in the policy’s default class and transitions; it does not change remote objects.

Selecting Unsupported clears the duration, retrieval tier, and version settings. Selecting Forbidden for a parameter clears its dependent values. Configure these values again if you subsequently enable the options.

Change storage class on the same object is evaluated for each destination class. The actual write path must be available and allowed for that class: Copy object for a single-request server-side copy, Single-request upload for a single-request relay through S3Client, or Start multipart upload for a multipart transfer. Multipart transfers require Multipart upload under Transfers; Multipart server-side copy is required only for server-side multipart copies. Properties and recursive changes offer only permitted destinations. Clearing this option does not block a rewrite that preserves the existing class.

Default class describes the destination class used when S3Client lets the service choose, without an x-amz-storage-class header. It also interprets a successful HeadObject response that provides no storage class header. A class missing from a listing remains unknown: S3Client reads metadata through HeadObject before a read or rewrite that depends on this information. A missing listing value therefore does not mean STANDARD. An incorrect default can misrepresent the expected destination class or the class interpreted after HEAD; adjust the policy and its assignments for the bucket.

In Transitions, click Add… or Edit…. Storage class transition requires distinct Source class and Target class values, at least one scope (Current versions, Noncurrent versions), and at least one compatible versioning state (Never enabled, Suspended, Enabled).

Check Minimum days since object creation, Minimum days since version became noncurrent, and Minimum time in source class to declare minimum delays in days, starting at 0. The first two depend on the selected scope; unchecking the scope clears the corresponding delay. Default minimum object size sets a size in bytes, starting at 0; An S3 size filter may override the default declares that an explicit size filter may replace it and is available only when the minimum size is checked. These fields declare accepted constraints; they do not create a transition rule in a bucket.

In Supported operations, separately declare:

• Restore status in ListObjects, Restore status in ListObjectsV2, and Restore status in ListObjectVersions, to request the optional RestoreStatus attribute in those listings.
• Read Intelligent-Tiering configuration, Create or update Intelligent-Tiering configuration, List Intelligent-Tiering configurations, and Delete Intelligent-Tiering configuration, for the corresponding APIs.

Lifecycle#

Read bucket lifecycle rules, Create or replace bucket lifecycle rules, and Remove all bucket lifecycle rules declare APIs for reading, replacing all rules, and deleting the configuration. Removing the configuration stops future actions; the request does not itself delete objects.

The selected policy’s Features tab specifies accepted rule elements:

Under Features > Rule constraints, select the supported rule statuses (Enabled rules, Disabled rules) and bucket states (Buckets never versioned, Buckets with suspended versioning, Buckets with enabled versioning). Require paired expiration rules requires After a number of days and Remove delete markers with no remaining versions: check these two options first. It requires two rules with the same filter and status: expiration after a number of days and removal of expired delete markers. Rule identifiers do not determine pairing.

For Backblaze B2, the lifecycle policy allows only enabled rules on buckets with enabled versioning and requires Require paired expiration rules.

In Limits, check Maximum tag conditions per rule to set a limit from 1 to 10, and Maximum actions per rule to set a positive limit. An unchecked limit adds no bound in this policy; service and S3 format limits still apply.

Dependencies are adjusted automatically. Maximum tag conditions per rule requires Tags; Retain newer noncurrent versions from deletion requires Expiration; Keep newer noncurrent versions in their storage class and Multiple noncurrent transitions require Noncurrent version after days; Multiple current transitions requires Current version after days or Current version at a date. Unchecking a prerequisite clears dependent settings, which you must restore if you enable it again.

These declarations do not schedule expiration. Remote rules are created in bucket properties and can permanently delete data; consult lifecycle rules before applying them.

Static website hosting#

In the policy’s Features, declare GetBucketWebsite for reading, PutBucketWebsite for creating or replacing, and DeleteBucketWebsite for removing the configuration. RedirectAllRequestsTo allows redirecting all requests to another host; RoutingRules allows conditional redirects.

The properties editor requires a successful read before writing or deleting. Checking only PutBucketWebsite is therefore insufficient to edit the website in the interface. These options neither publish a site nor make objects public. Use bucket properties for remote configuration.

Bucket access logging#

The last two options supplement write configuration; they do not enable logging on their own. Destination bucket permissions and ACL state still apply. See Log bucket access.

The compatibility dropdown offers Strict S3 XML or Preserve known logging additions. The second option preserves known fields in a standard logging configuration, such as ObjectRollTime and RecordsBatchSize, when you update it. Disabling logging removes them. It does not offer controls to create these fields. Unknown additions remain uneditable. See access logging.

ACL policy#

Enable ACL operations for this account enables local ACL use. Unchecking it disables the policy tabs without revoking remote permissions; their settings are retained. These settings describe service compatibility; they do not replace the resource ACL editor.

When this option is unchecked, properties no longer offer an ACL tab. Ordinary transfers and property rewrites use the destination default without ACL requests or headers. This does not guarantee preservation of existing ACLs if the service still uses them. An explicit ACL request or an incompatible preservation requirement is still rejected. See the effects of local deactivation.

Set access log target grants remains independent of this option: TargetGrants belong to the logging configuration, not to resource ACL operations. The destination’s Bucket owner enforced mode still imposes its restrictions.

The Operation lists under Request forms, Canned ACLs, and Explicit grants offer Replace bucket ACL, Single-request upload, Copy object, Start multipart upload, and Replace object ACL. Buckets accept only private, public-read, public-read-write, and authenticated-read; the other three canned ACLs apply to objects. The WRITE permission and the http://acs.amazonaws.com/groups/s3/LogDelivery group are restricted to bucket operations. An incompatible choice blocks validation instead of being corrected automatically.

To save a rule under Error rules, meet the requirements for its Action:

• Require Object Ownership check requires a write operation and Any write form / none.
• Mark operation as unsupported requires Any write form / none and rejects the AccessDenied code.
• Mark request form as unsupported requires a specific write form compatible with the operation and rejects the AccessDenied code.

Two rules for the same operation and error code cannot cover both the same HTTP statuses and the same write forms. Any write form / none covers all forms. Overlapping rules block validation.

ACL limits allow up to 1,000 values per collection and 7,000 error rules. Configure exact service error codes; do not treat an access error as an unsupported API declaration. Uploads and copies have their own ACL settings, separate from later ACL replacement. To change resource permissions, use ACLs and object ownership.

An enabled ACL policy requires at least one supported API. Object APIs require a corresponding read or write scope; read scope is independent of Object ACL response, so a bucket projection can cover the current object alone or explicit versions. Write forms must agree with the selected canned ACLs, permissions, and Preferred encoding. Try grant headers, then XML if unsupported requires both Grant headers and AccessControlPolicy XML body. Inconsistencies produce Invalid ACL policy: and block saving until corrected.

Read scope and response semantics are separate settings. To view bucket permissions projected onto object versions, select Current object and specific versions under Object ACL read scope, and Object ACL derived from the bucket ACL under Object ACL response, when supported by the service. This enables viewing, without editing or claiming exact preservation of an independent object ACL.

General request limits#

Open File > Accounts…, select the account and choose Edit…. On the Account tab, the Connection group contains Maximum PUT header bytes and Maximum POST header bytes. These settings limit the complete headers of the corresponding requests, even when ACLs are disabled. 0, displayed as No configured limit, sets no limit. Oversized requests are rejected before being sent; the same limits also affect ACL encoding selection. Click OK to save.

An account created from Amazon S3 has a PUT limit of 8,192 bytes and no configured POST limit. S3-compatible storage leaves both limits unconfigured. Custom presets supply their own values; applying a preset to an existing account also replaces these limits.