To protect files in an OSS bucket from accidental or malicious changes, you can configure a prevent-overwrite rule. This feature lets you precisely control which files cannot be overwritten based on their path, type, or the user's identity.
Concurrent writes and prevent-overwrite rules: In high-concurrency scenarios, such as when multiple clients write to a non-existent path or a write occurs during a deletion, the system may not find an existing file to overwrite. In these cases, the write operation is allowed. However, once the file is successfully created, the rule will block any subsequent attempts to overwrite it.
Storage class transition limitations: When the File overwrite prohibited feature is enabled, you cannot use client-side methods like the OSS console, SDKs, or ossutil to call the CopyObject operation to change an object's storage class, for example, from Standard to Archive. To change the storage class of protected objects, use lifecycle rules for automatic transitions.
Feature compatibility: The File overwrite prohibited feature only blocks client-side file overwrite operations. It does not affect background system functions such as cross-region replication (CRR) or lifecycle rules.
Conflict with versioning: The File overwrite prohibited feature is mutually exclusive with versioning. If versioning is enabled or suspended for a bucket, any prevent-overwrite rules are ignored.
How it works
When OSS receives a request to overwrite a file, the system evaluates the request against the configured prevent-overwrite rules in the order of their creation:
Rule matching: The system checks if the file path matches the prefix and suffix conditions of a rule and if the user's identity matches the Authorized User setting.
Decision: OSS blocks the overwrite and returns a
FileAlreadyExistserror only if all conditions in a rule (prefix, suffix, and user identity) are met.Default behavior: If a request does not match any prevent-overwrite rule, the overwrite is allowed.
Protect specific file types
Protect configuration and log files in your production environment from being accidentally overwritten by specific users.
On the Buckets page, click the name of the target bucket.
In the left navigation pane, choose .
Click New rule added to prohibit overwrite writes and configure the following parameters:
Rule ID: You can enter a custom ID or leave it blank for an automatically generated one.
File name prefix: Enter the directory path to protect, such as
production/configs/.File name extension: Enter the file extension to protect, such as
.json.Authorized User: Specify the RAM users, RAM roles, or other accounts to restrict.
Click OK to create the rule.
Verify the rule:
Using a restricted account, try to upload a file with the same name to
production/configs/app.json.Confirm that a
FileAlreadyExistserror is returned.Confirm that other users can upload files normally and that uploads to paths that do not meet the prefix and suffix conditions are successful.
Set a global protection policy
Establish comprehensive protection for critical business data to prevent accidental modifications by any user.
On the Buckets page, click the name of the target bucket.
In the left navigation pane, choose .
Click New rule added to prohibit overwrite writes and configure the following parameters:
Rule ID: You can enter a custom ID or leave it blank for an automatically generated one.
File name prefix:
critical-data/File name extension: Leave this blank to protect all files in the specified path.
Authorized User:
*(all accounts)
Click OK to create the rule.
Verify the global protection:
Using any account, try to overwrite
critical-data/database.sql.Confirm that a
FileAlreadyExistserror is returned, which indicates that global protection is active.Confirm that files in other paths, such as
public-data/, can still be overwritten.
Matching rules
Number of rules: A single bucket can have a maximum of 100 rules.
Character length: The maximum length for a prefix or suffix is 1,023 characters.
Prefix and suffix matching: Only exact string matching is supported. Regular expressions and wildcards are not supported. OSS treats an input such as
logs/as literal characters.Prefix matching: A prefix of
logs/matcheslogs/app.logbut does not matchdev-logs/app.log.Suffix matching: A suffix of
.txtmatchesreadme.txtbut does not matchreadme.TXT(case-sensitive) orreadme.txt.bak.Authorized User matching: The asterisk (
*) wildcard is supported. For configuration details, see the Principal element in Common examples of a bucket policy.Condition logic: OSS blocks the overwrite only if all conditions in a rule (prefix, suffix, and Authorized User) are met.
Rule ID: This parameter is optional. If you leave this field blank, OSS automatically generates a universally unique identifier (UUID). If you provide an ID, it must be unique within the bucket.
File overwrite operations
This feature blocks the following client-side file overwrite operations:
PutObject
PostObject
CopyObject
PutObjectSymlink
InitiateMultipartUpload
CompleteMultipartUpload
FAQ
Why can't the bucket owner overwrite files?
This is expected behavior. A blank Authorized User field applies the rule to all users, including the bucket owner and the root account. To restore overwrite permissions, you can:
Delete the rule in the console.
Modify the rule's prefix or suffix to narrow its scope.
Set the Authorized User to specific accounts to restrict only those users.
Why doesn't the prefix logs/*.txt work?
OSS does not support wildcards for prefix and suffix matching. The * character is treated as a literal character, and the system performs an exact match for a file named logs/*.txt. The correct method is:
Set the prefix to
logs/Set the suffix to
.txt
This matches all files in the logs/ directory that end with .txt.
What happens with blank prefix and suffix fields?
When both the prefix and suffix are left blank, the rule applies to the entire bucket. This means:
If the Authorized User field is also blank, all users are prevented from overwriting any file in the bucket.
If the Authorized User field specifies certain accounts, only those users are restricted from overwriting files in the bucket.
Why are some write operations not blocked?
A prevent-overwrite rule only blocks write operations on files that already exist. During concurrent writes, such as when multiple clients write to a non-existent path or when a write is initiated during a deletion, the system may not find an existing file to overwrite. In such race conditions, the write operation proceeds. This does not mean the rule has failed. After the file is created, the rule will block any subsequent attempts to overwrite it. Additionally, the rule cannot block an operation that is not in the list of file overwrite operations.